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: 4+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox