Re: [PATCH bpf v4 2/3] bpf: Avoid faultable build ID reads under mm locks

[Ihor Solodrai]

On 5/14/26 1:47 PM, Shakeel Butt wrote:
> On Thu, May 14, 2026 at 11:47:26AM -0700, Ihor Solodrai wrote:
>> Sleepable build ID parsing can block in __kernel_read() [1], so the
>> stackmap sleepable path must not call it while holding mmap_lock or a
>> per-VMA read lock.
>>
>> The issue and the fix are conceptually similar to a recent procfs
>> patch [2].
>>
>> Resolve each covered VMA with a stable read-side reference, preferring
>> lock_vma_under_rcu() and falling back to mmap_read_trylock()
> 
> Why trylock()? Why not just reuse the mechanism introduced in [2]? That is
> abstract out the mechanism introduced in [2] in mm core and reuse it.

v1 used mmap_read_lock() as the fallback, but Puranjay pointed out [1]
that stackmap can be called when the caller already holds
mmap_lock. So I changed to trylock since v2, similar to non-sleepable
path.

AFAIU this means that the common mechanism needs to support trylock
behavior as in stack_map_lock_vma() in this patch.

Do you think this is worth factoring out of stackmap.c?

[1] https://lore.kernel.org/bpf/m25x611s17.fsf@xxxxxxxxxx/

> 
> 
>> only long
>> enough to acquire the VMA read lock. Take a reference to the backing
>> file, drop the VMA lock, and then parse the build ID through
>> (sleepable) build_id_parse_file().
>>
>> [1]: https://lore.kernel.org/all/20251218005818.614819-1-shakeel.butt@xxxxxxxxx/
>> [2]: https://lore.kernel.org/all/20260128183232.2854138-1-andrii@xxxxxxxxxx/
>>