From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: bot+bpf-ci@kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, song@kernel.org
Cc: puranjay@kernel.org, shakeel.butt@linux.dev, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
martin.lau@kernel.org, eddyz87@gmail.com,
yonghong.song@linux.dev, clm@meta.com
Subject: Re: [PATCH bpf v1] bpf: Avoid faultable build ID reads under mm locks
Date: Tue, 7 Apr 2026 19:54:51 -0700 [thread overview]
Message-ID: <72c8f96e-1e07-4665-9581-2aac3b8d789f@linux.dev> (raw)
In-Reply-To: <e243df5b89176efe6cdf678bf9d588d619ad6d8426b1973e1beb4cf1c650c6c4@mail.kernel.org>
On 4/7/26 6:05 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
>> index da3d328f5c15..017ecbc22c96 100644
>> --- a/kernel/bpf/stackmap.c
>> +++ b/kernel/bpf/stackmap.c
>
> [ ... ]
>
>> +static void stack_map_get_build_id_offset_sleepable(struct bpf_stack_build_id *id_offs,
>> + u32 trace_nr)
>> +{
>> + struct mm_struct *mm = current->mm;
>> + struct vm_area_struct *vma;
>> + struct file *file;
>> + u64 ip;
>> +
>> + for (u32 i = 0; i < trace_nr; i++) {
>> + ip = READ_ONCE(id_offs[i].ip);
>> + vma = stack_map_lock_vma(mm, ip);
>> + if (!range_in_vma(vma, ip, ip) || !vma->vm_file) {
>> + stack_map_build_id_set_ip(&id_offs[i]);
>> + if (vma)
>> + vma_end_read(vma);
>> + continue;
>> + }
>> +
>> + file = get_file(vma->vm_file);
>> + vma_end_read(vma);
>> +
>> + /* build_id_parse_file() may block on filesystem reads */
>> + if (build_id_parse_file(file, id_offs[i].build_id, NULL)) {
>> + stack_map_build_id_set_ip(&id_offs[i]);
>> + } else {
>> + id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ip - vma->vm_start;
>> + id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
>> + }
>
> After vma_end_read(vma) drops the per-VMA read lock, can vma->vm_pgoff
> and vma->vm_start still be safely accessed here? It looks like the VMA
> could be split, merged, or freed by another thread while
> build_id_parse_file() blocks on filesystem I/O.
>
> The non-sleepable path in stack_map_get_build_id_offset() reads these
> same fields under mmap_read_lock, which keeps the VMA stable. Here the
> lock is already gone.
>
> Saving vm_pgoff and vm_start to local variables before vma_end_read()
> would close the window, similar to the approach in the procfs patch
> referenced in the commit message.
I think AI is right here. Will wait a bit for feedback before sending v2.
>
>> +
>> + fput(file);
>> + }
>> +}
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24111574515
next prev parent reply other threads:[~2026-04-08 2:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 22:30 [PATCH bpf v1] bpf: Avoid faultable build ID reads under mm locks Ihor Solodrai
2026-04-08 1:05 ` bot+bpf-ci
2026-04-08 2:54 ` Ihor Solodrai [this message]
2026-04-08 13:49 ` Puranjay Mohan
2026-04-11 10:34 ` kernel test robot
2026-04-11 10:45 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72c8f96e-1e07-4665-9581-2aac3b8d789f@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=puranjay@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.