Re:Re: Question: BPF stack build-id lookup while holding mmap_lock
From: Runyu Xiao
Date: Thu Jun 18 2026 - 01:25:49 EST
Hi,
Thanks for pointing this out, and sorry for missing the existing series.
I checked the linked patch and it covers the same lock-ordering issue I
was concerned about in the sleepable stackmap build-id path. I will drop
my local draft and avoid sending a duplicate patch.
Thanks,
Runyu
Original:
From：Ihor Solodrai <ihor.solodrai@xxxxxxxxx>
Date：2026-06-18 13:05:24(中国 (GMT+08:00))
To：Runyu Xiao <runyu.xiao@xxxxxxxxxx> , Song Liu <song@xxxxxxxxxx> , Alexei Starovoitov <ast@xxxxxxxxxx> , Daniel Borkmann <daniel@xxxxxxxxxxxxx> , Andrii Nakryiko <andrii@xxxxxxxxxx>
Cc：Jiri Olsa <jolsa@xxxxxxxxxx> , Martin KaFai Lau <martin.lau@xxxxxxxxx> , Eduard Zingerman <eddyz87@xxxxxxxxx> , Yonghong Song <yonghong.song@xxxxxxxxx> , John Fastabend <john.fastabend@xxxxxxxxx> , KP Singh <kpsingh@xxxxxxxxxx> , Stanislav Fomichev <sdf@xxxxxxxxxxx> , Hao Luo <haoluo@xxxxxxxxxx> , bpf<bpf@xxxxxxxxxxxxxxx> , linux-kernel<linux-kernel@xxxxxxxxxxxxxxx> , jianhao.xu<jianhao.xu@xxxxxxxxxx>
Subject：Re: Question: BPF stack build-id lookup while holding mmap_lock
On 6/17/26 8:31 PM, Runyu Xiao wrote:
> Hi,
>
> While auditing lock ordering around faultable build-id lookups, our
> static analysis tool flagged the BPF stackmap user-build-id path, and we
> manually reviewed it against the current tree.
>
> The path we are concerned about is the sleepable helper path:
>
> bpf_get_stack_sleepable() / bpf_get_task_stack_sleepable()
> -> __bpf_get_stack(..., may_fault = true)
> -> stack_map_get_build_id_offset()
> -> mmap_read_trylock(current->mm)
> -> build_id_parse(vma, ...)
> -> __kernel_read()
>
> `build_id_parse()` can read from the backing file while mmap_lock is
> held. That can form an ABBA dependency with file read paths where the
> inode side is held first and copy_to_user/copy_page_to_iter can fault
> and then need mmap_lock.
>
> A minimal Lockdep reproducer preserving this BPF stackmap carrier and
> the reverse file-read edge reports:
>
> WARNING: possible circular locking dependency detected
> __kernel_read
> stack_map_get_build_id_offset
> __bpf_get_stack
> *** DEADLOCK ***
>
> The local fix I am considering is only for the faultable build-id path.
> It would snapshot the VMA file reference and offset metadata under
> mmap_lock, drop mmap_lock, and then parse the build-id from the file
> reference with build_id_parse_file(). The existing no-fault path would
> remain unchanged.
>
> Roughly:
>
> 1. Under mmap_lock, find the VMA for each user IP.
> 2. Take a file reference and snapshot vm_start/vm_pgoff.
> 3. Drop mmap_lock.
> 4. Parse build IDs from the files.
> 5. Fall back to reporting IPs if the faultable path cannot safely
> release mmap_lock or allocate the temporary snapshot array.
Hi Runyu,
A patch implementing more or less this algorithm has recently landed:
https://lore.kernel.org/bpf/20260525223948.1920986-1-ihor.solodrai@xxxxxxxxx/
I recommend doing a search on lore.kernel.org or other mailing list mirror
in advance, to avoid unnecessary or duplicate work.
>
> The tradeoff is that build-id parsing would happen after releasing
> mmap_lock, so the VMA/file relationship is represented by the file
> reference and copied metadata rather than by holding the VMA lock context
> through the file read. That avoids file I/O under mmap_lock, but may
> change edge-case behavior if the mapping changes concurrently.
>
> Does this direction sound acceptable for sleepable BPF stack helpers, or
> would you prefer a stricter fallback-to-IP behavior whenever build-id
> parsing would require faultable file I/O? Another option would be to
> avoid build-id parsing entirely in the may_fault=true stackmap path unless
> there is an existing BPF/MM helper pattern I should reuse.
>
> The local draft subject is:
>
> bpf: avoid faultable build-id lookup under mmap_lock
>
> Thanks,
> Runyu
</jianhao.xu@xxxxxxxxxx></linux-kernel@xxxxxxxxxxxxxxx></bpf@xxxxxxxxxxxxxxx></haoluo@xxxxxxxxxx></sdf@xxxxxxxxxxx></kpsingh@xxxxxxxxxx></john.fastabend@xxxxxxxxx></yonghong.song@xxxxxxxxx></eddyz87@xxxxxxxxx></martin.lau@xxxxxxxxx></jolsa@xxxxxxxxxx></andrii@xxxxxxxxxx></daniel@xxxxxxxxxxxxx></ast@xxxxxxxxxx></song@xxxxxxxxxx></runyu.xiao@xxxxxxxxxx></ihor.solodrai@xxxxxxxxx>