Message ID | 20230201135737.800527-1-jolsa@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp311021wrn; Wed, 1 Feb 2023 06:31:25 -0800 (PST) X-Google-Smtp-Source: AK7set91XvwgHiClb7nPWAqdoLau4VBNisWp7ZQWFJG1ChVPn3ZP4qovZJdbjnb6j4XI7cHQneG+ X-Received: by 2002:a50:9eca:0:b0:4a2:4abc:29d4 with SMTP id a68-20020a509eca000000b004a24abc29d4mr2561253edf.32.1675261885549; Wed, 01 Feb 2023 06:31:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675261885; cv=none; d=google.com; s=arc-20160816; b=qLJwD0McO6LKLJlY+pZJrDgfWjy+RJqEG6jDOgeZhfIz69O+l5XruM5zAt5VA9OUoN 5ghmcPlON+ErYbOVD3t+5F3WXvDQhHDyXxrbXv6FRG3uRktUuFpExuK5QUc9cVnuyqtU ig1tOwJvHpY6fXaPcpf6hAfXoEY9AISKnPWIaMf93N1kFdLoLYgf5sRoZk9xTKzUAT/O Z+qpyNc8XLRz7my0Go6borLw8+fPsvFJOocYjWDGWP8du4p1+tvNOazUyYMAH8k4WQlv Vsz2SKWqedlNaVd0Qy3C+sZhQIPO+/pe1ucvZ38yUDAnAy+VtVuwmwoD3vZCmxRZQJYN 400w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=pNf9IOnnyCHBNYxsNOyGJgszqUAP3+Wd4NQfoX8s1Tk=; b=eywAEE8qgQgPgCoo12XU3BaDrQelyjeHEhX7GODaokjsbtwi0KGGVp7PtNIhUc8hvy vjqt0GbtYLdPxSyXMkgRWYrn1eb8jcBd9CNvWXoGvkjx6XlhT+1yHlVz8dKzYCyVwBGs mSBpdI+Goq6+1G2TfloBc82+LxLMEOWx/gAcU+rZv05TDmz3/EmF91hMHS6SQ47FTOvA p0aepyu64zqzv1sI7cYA3neiBtKrsDjkqiXrW9FL9hJ/mF/qfwnQa1/yvJabbOo5Ihhb CVsWDkWVsm9UZ03xjxB95sO/s6pKaXW5gMaOfwZg78uKzoMf3zWf2n2PYulGUpqmi7Wq vXzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J+gWjVwh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fq14-20020a1709069d8e00b0088442bcb2b4si13383329ejc.327.2023.02.01.06.31.02; Wed, 01 Feb 2023 06:31:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J+gWjVwh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231685AbjBAN6P (ORCPT <rfc822;duw91626@gmail.com> + 99 others); Wed, 1 Feb 2023 08:58:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231482AbjBAN6K (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Feb 2023 08:58:10 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4213693F0; Wed, 1 Feb 2023 05:57:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F0C40617B2; Wed, 1 Feb 2023 13:57:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9C58C433EF; Wed, 1 Feb 2023 13:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675259864; bh=SpI7KwADUFU7LsbCXaag3YbpvOzij0u/n2sLMpli8zM=; h=From:To:Cc:Subject:Date:From; b=J+gWjVwhlExx/kQG6HBH333Bk6FbQ3RN+UdWZ0kJIewW9wN3j8Mf3kQteaovGFv86 u2oE9NGNpu9NmrB/ownkgk2gQKCRIj2OedRN4vuA9WhTshG4lufDkeknzyQkpY6UdY AS6p64fr4NTxNvP/d5OkLNkzWL0qydlmOkQsI5l0bUeDwiPxwZB8EHJbZUyDFuFtbI sEijVQfSNJq7AqeMorekg6Z+53JqVokPn71gIEW/2r6QhiHNzBidvbYlGC3TeIdTsU cmSJkCagjvADr3IrUJ8WtYRbFaLwYhz0B0axL1N+J6ahLdweQ+b24KAxeJAbjW5ard H//g0Cj7MvffA== From: Jiri Olsa <jolsa@kernel.org> To: Alexei Starovoitov <ast@kernel.org>, Andrii Nakryiko <andrii@kernel.org>, Hao Luo <haoluo@google.com>, Andrew Morton <akpm@linux-foundation.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org> Cc: bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@chromium.org>, Stanislav Fomichev <sdf@google.com>, Daniel Borkmann <daniel@iogearbox.net> Subject: [RFC 0/5] mm/bpf/perf: Store build id in file object Date: Wed, 1 Feb 2023 14:57:32 +0100 Message-Id: <20230201135737.800527-1-jolsa@kernel.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756639407071268737?= X-GMAIL-MSGID: =?utf-8?q?1756639407071268737?= |
Series |
mm/bpf/perf: Store build id in file object
|
|
Message
Jiri Olsa
Feb. 1, 2023, 1:57 p.m. UTC
hi, we have a use cases for bpf programs to use binary file's build id. After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] to store build id directly in the file object. That would solve our use case and might be beneficial for other profiling/tracing use cases with bpf programs. This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds build id object pointer to the file object when enabled. The build id is read/populated when the file is mmap-ed. I also added bpf and perf changes that would benefit from this. I'm not sure what's the policy on adding stuff to file object, so apologies if that's out of line. I'm open to any feedback or suggestions if there's better place or way to do this. thanks, jirka [1] https://lore.kernel.org/bpf/20221108222027.3409437-1-jolsa@kernel.org/ [2] https://lore.kernel.org/bpf/20221128132915.141211-1-jolsa@kernel.org/ [3] https://lore.kernel.org/bpf/CAEf4BzaZCUoxN_X2ALXwQeFTCwtL17R4P_B_-hUCcidfyO2xyQ@mail.gmail.com/ --- Jiri Olsa (5): mm: Store build id in file object bpf: Use file object build id in stackmap perf: Use file object build id in perf_event_mmap_event selftests/bpf: Add file_build_id test selftests/bpf: Add iter_task_vma_buildid test fs/file_table.c | 3 +++ include/linux/buildid.h | 17 +++++++++++++++++ include/linux/fs.h | 3 +++ kernel/bpf/stackmap.c | 8 ++++++++ kernel/events/core.c | 43 +++++++++++++++++++++++++++++++++++++++---- lib/buildid.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ mm/Kconfig | 7 +++++++ mm/mmap.c | 15 +++++++++++++++ tools/testing/selftests/bpf/prog_tests/bpf_iter.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/prog_tests/file_build_id.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/progs/file_build_id.c | 34 ++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/trace_helpers.c | 35 +++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/trace_helpers.h | 1 + 14 files changed, 413 insertions(+), 4 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/file_build_id.c create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c create mode 100644 tools/testing/selftests/bpf/progs/file_build_id.c
Comments
On Wed, Feb 1, 2023 at 5:57 AM Jiri Olsa <jolsa@kernel.org> wrote: > > hi, > we have a use cases for bpf programs to use binary file's build id. > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > to store build id directly in the file object. That would solve our use > case and might be beneficial for other profiling/tracing use cases with > bpf programs. > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > build id object pointer to the file object when enabled. The build id is > read/populated when the file is mmap-ed. > > I also added bpf and perf changes that would benefit from this. > > I'm not sure what's the policy on adding stuff to file object, so apologies > if that's out of line. I'm open to any feedback or suggestions if there's > better place or way to do this. struct file represents all files while build_id is for executables only, and not all executables, but those currently running, so I think it's cleaner to put it into vm_area_struct.
On Thu, Feb 02, 2023 at 03:15:39AM -0800, Alexei Starovoitov wrote: > On Wed, Feb 1, 2023 at 5:57 AM Jiri Olsa <jolsa@kernel.org> wrote: > > > > hi, > > we have a use cases for bpf programs to use binary file's build id. > > > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > > to store build id directly in the file object. That would solve our use > > case and might be beneficial for other profiling/tracing use cases with > > bpf programs. > > > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > > build id object pointer to the file object when enabled. The build id is > > read/populated when the file is mmap-ed. > > > > I also added bpf and perf changes that would benefit from this. > > > > I'm not sure what's the policy on adding stuff to file object, so apologies > > if that's out of line. I'm open to any feedback or suggestions if there's > > better place or way to do this. > > struct file represents all files while build_id is for executables only, > and not all executables, but those currently running, so > I think it's cleaner to put it into vm_area_struct. I thought file objects would be shared to some extend and we might save some memory keeping the build id objects there, but not sure it's really the case now.. will check, using vma might be also easier jirka
On Wed, Feb 01, 2023 at 02:57:32PM +0100, Jiri Olsa wrote: > hi, > we have a use cases for bpf programs to use binary file's build id. What is your use case? Is it some hobbyist thing or is it something that distro kernels are all going to enable?
On Thu, Feb 02, 2023 at 03:10:30PM +0000, Matthew Wilcox wrote: > On Wed, Feb 01, 2023 at 02:57:32PM +0100, Jiri Olsa wrote: > > hi, > > we have a use cases for bpf programs to use binary file's build id. > > What is your use case? Is it some hobbyist thing or is it something > that distro kernels are all going to enable? > our use case is for hubble/tetragon [1] and we are asked to report buildid of executed binary.. but the monitoring process is running in its own pod and can't access the the binaries outside of it, so we need to be able to read it in kernel I understand Hao Luo has also use case for that [2] jirka [1] https://github.com/cilium/tetragon/ [2] https://lore.kernel.org/bpf/CA+khW7gAYHmoUkq0UqTiZjdOqARLG256USj3uFwi6z_FyZf31w@mail.gmail.com/
On Thu, Feb 02, 2023 at 03:15:39AM -0800, Alexei Starovoitov wrote: > On Wed, Feb 1, 2023 at 5:57 AM Jiri Olsa <jolsa@kernel.org> wrote: > > > > hi, > > we have a use cases for bpf programs to use binary file's build id. > > > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > > to store build id directly in the file object. That would solve our use > > case and might be beneficial for other profiling/tracing use cases with > > bpf programs. > > > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > > build id object pointer to the file object when enabled. The build id is > > read/populated when the file is mmap-ed. > > > > I also added bpf and perf changes that would benefit from this. > > > > I'm not sure what's the policy on adding stuff to file object, so apologies > > if that's out of line. I'm open to any feedback or suggestions if there's > > better place or way to do this. > > struct file represents all files while build_id is for executables only, > and not all executables, but those currently running, so > I think it's cleaner to put it into vm_area_struct. There can be many vm_area_structs per file, and like for struct file, there's vm_area_structs for non-executable ranges too. Given there's only one buildid per file, struct file seems most appropriate to me.
On Thu, Feb 2, 2023 at 7:33 AM Jiri Olsa <olsajiri@gmail.com> wrote: > > On Thu, Feb 02, 2023 at 03:10:30PM +0000, Matthew Wilcox wrote: > > On Wed, Feb 01, 2023 at 02:57:32PM +0100, Jiri Olsa wrote: > > > hi, > > > we have a use cases for bpf programs to use binary file's build id. > > > > What is your use case? Is it some hobbyist thing or is it something > > that distro kernels are all going to enable? > > > > our use case is for hubble/tetragon [1] and we are asked to report > buildid of executed binary.. but the monitoring process is running > in its own pod and can't access the the binaries outside of it, so > we need to be able to read it in kernel > > I understand Hao Luo has also use case for that [2] > Sorry for the late reply. We use BPF to profile stacktraces and build id is more useful than instruction addresses. However, sometimes we need to record stacktraces from an atomic context. In that case, if the page that contains the build id string is not in the page cache, we would fail to get build id. Storing the build id in file object solves this problem and helps us get build id more reliably. > jirka > > > [1] https://github.com/cilium/tetragon/ > [2] https://lore.kernel.org/bpf/CA+khW7gAYHmoUkq0UqTiZjdOqARLG256USj3uFwi6z_FyZf31w@mail.gmail.com/
On Wed, Feb 01, 2023 at 02:57:32PM +0100, Jiri Olsa wrote: > hi, > we have a use cases for bpf programs to use binary file's build id. > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > to store build id directly in the file object. That would solve our use > case and might be beneficial for other profiling/tracing use cases with > bpf programs. > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > build id object pointer to the file object when enabled. The build id is > read/populated when the file is mmap-ed. > > I also added bpf and perf changes that would benefit from this. > > I'm not sure what's the policy on adding stuff to file object, so apologies > if that's out of line. I'm open to any feedback or suggestions if there's > better place or way to do this. hi, Matthew suggested on irc to consider inode for storing build id I tried that and it seems to have better stats wrt allocated build id objects, because inode is being shared among file objects I took /proc/slabinfo output after running bpf tests - build id stored in file: # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> build_id 668 775 160 25 1 : tunables 0 0 0 : slabdata 31 31 0 - build id stored in inode: # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> build_id 222 225 160 25 1 : tunables 0 0 0 : slabdata 9 9 0 I'm stranger to inode/fs/mm code so I'll spend some time checking on what I possibly broke in there before I send it, but I'd appreciate any early feedback ;-) the code is in here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git inode_build_id I'll send another version with inode if there's no objection thanks, jirka > > thanks, > jirka > > > [1] https://lore.kernel.org/bpf/20221108222027.3409437-1-jolsa@kernel.org/ > [2] https://lore.kernel.org/bpf/20221128132915.141211-1-jolsa@kernel.org/ > [3] https://lore.kernel.org/bpf/CAEf4BzaZCUoxN_X2ALXwQeFTCwtL17R4P_B_-hUCcidfyO2xyQ@mail.gmail.com/ > --- > Jiri Olsa (5): > mm: Store build id in file object > bpf: Use file object build id in stackmap > perf: Use file object build id in perf_event_mmap_event > selftests/bpf: Add file_build_id test > selftests/bpf: Add iter_task_vma_buildid test > > fs/file_table.c | 3 +++ > include/linux/buildid.h | 17 +++++++++++++++++ > include/linux/fs.h | 3 +++ > kernel/bpf/stackmap.c | 8 ++++++++ > kernel/events/core.c | 43 +++++++++++++++++++++++++++++++++++++++---- > lib/buildid.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ > mm/Kconfig | 7 +++++++ > mm/mmap.c | 15 +++++++++++++++ > tools/testing/selftests/bpf/prog_tests/bpf_iter.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/prog_tests/file_build_id.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/progs/file_build_id.c | 34 ++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/trace_helpers.c | 35 +++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/trace_helpers.h | 1 + > 14 files changed, 413 insertions(+), 4 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/file_build_id.c > create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c > create mode 100644 tools/testing/selftests/bpf/progs/file_build_id.c
Hi Jiri, On Thu, Feb 9, 2023 at 6:25 AM Jiri Olsa <olsajiri@gmail.com> wrote: > > On Wed, Feb 01, 2023 at 02:57:32PM +0100, Jiri Olsa wrote: > > hi, > > we have a use cases for bpf programs to use binary file's build id. > > > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > > to store build id directly in the file object. That would solve our use > > case and might be beneficial for other profiling/tracing use cases with > > bpf programs. > > > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > > build id object pointer to the file object when enabled. The build id is > > read/populated when the file is mmap-ed. > > > > I also added bpf and perf changes that would benefit from this. Thanks for working on this! > > > > I'm not sure what's the policy on adding stuff to file object, so apologies > > if that's out of line. I'm open to any feedback or suggestions if there's > > better place or way to do this. > > hi, > Matthew suggested on irc to consider inode for storing build id Yeah, that's my idea too. > > I tried that and it seems to have better stats wrt allocated build > id objects, because inode is being shared among file objects > > I took /proc/slabinfo output after running bpf tests > > - build id stored in file: > > # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> > build_id 668 775 160 25 1 : tunables 0 0 0 : slabdata 31 31 0 > > - build id stored in inode: > > # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> > build_id 222 225 160 25 1 : tunables 0 0 0 : slabdata 9 9 0 Cool! > > > I'm stranger to inode/fs/mm code so I'll spend some time checking on > what I possibly broke in there before I send it, but I'd appreciate > any early feedback ;-) > > the code is in here: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > inode_build_id > > I'll send another version with inode if there's no objection I'll take a look. Thanks, Namhyung > > > > [1] https://lore.kernel.org/bpf/20221108222027.3409437-1-jolsa@kernel.org/ > > [2] https://lore.kernel.org/bpf/20221128132915.141211-1-jolsa@kernel.org/ > > [3] https://lore.kernel.org/bpf/CAEf4BzaZCUoxN_X2ALXwQeFTCwtL17R4P_B_-hUCcidfyO2xyQ@mail.gmail.com/ > > --- > > Jiri Olsa (5): > > mm: Store build id in file object > > bpf: Use file object build id in stackmap > > perf: Use file object build id in perf_event_mmap_event > > selftests/bpf: Add file_build_id test > > selftests/bpf: Add iter_task_vma_buildid test > > > > fs/file_table.c | 3 +++ > > include/linux/buildid.h | 17 +++++++++++++++++ > > include/linux/fs.h | 3 +++ > > kernel/bpf/stackmap.c | 8 ++++++++ > > kernel/events/core.c | 43 +++++++++++++++++++++++++++++++++++++++---- > > lib/buildid.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ > > mm/Kconfig | 7 +++++++ > > mm/mmap.c | 15 +++++++++++++++ > > tools/testing/selftests/bpf/prog_tests/bpf_iter.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/prog_tests/file_build_id.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/progs/file_build_id.c | 34 ++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/trace_helpers.c | 35 +++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/trace_helpers.h | 1 + > > 14 files changed, 413 insertions(+), 4 deletions(-) > > create mode 100644 tools/testing/selftests/bpf/prog_tests/file_build_id.c > > create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c > > create mode 100644 tools/testing/selftests/bpf/progs/file_build_id.c