Re: [PATCH bpf-next v4 1/4] bpf: Add a sleepable page allocator for map memory

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Aug 24, 2026 at 3:01 PM CEST, Michal Hocko wrote:
> On Mon 24-08-26 20:44:18, Jiayuan Chen wrote:
>>
>> On 8/24/26 8:26 PM, Michal Hocko wrote:
>> > On Fri 21-08-26 13:06:12, Jiayuan Chen wrote:
>> > > bpf_map_alloc_pages() picks the allocator via can_alloc_pages(), a
>> > > conservative guess for BPF program context that is always false under
>> > > PREEMPT_RT. So even a caller that really is sleepable gets the
>> > > non-blocking allocator, which never reclaims and never engages the OOM
>> > > machinery.
>> > I thought one of the main motivations was reentrancy. As you cannot
>> > really assume the context bpf_map_alloc_pages is called from there is an
>> > extra care needed so that this doesn't re-enter the allocator from bpf
>> > program called from allocator path and deadlock.
>>
>>
>> Agreed, bpf_map_alloc_pages() is designed to be safe to run in any context.
>>
>> The commit message should be precise.
>
> How do you achive any level of safety for the _sleepable version? Vast
> majority of the kernel is sleepable but that doesn't mean this is safe
> from the mm reentrancy POV.

I think it will only be invoked directly in the arena map fault handler, which
runs in task context. If an interrupt occurs and tries to allocate pages,
can_alloc_pages() will return false and it should pick the _nolock() variant
which is safe against reentrancy.