Re: [PATCH bpf-next v7 1/2] mm/bpf: Add bpf_proactive_reclaim kfunc

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

On Fri Sep 4, 2026 at 8:03 PM CEST, Andrew Morton wrote:
> On Fri,  4 Sep 2026 18:20:19 +0800 "Hui Zhu" <hui.zhu@linux.dev> wrote:
>
>> @@ -159,6 +160,74 @@ __bpf_kfunc void bpf_mem_cgroup_flush_stats(struct mem_cgroup *memcg)
>>  	mem_cgroup_flush_stats(memcg);
>>  }
>>
>> +/*
>> + * Reclaim must not recurse: try_to_free_mem_cgroup_pages() overwrites
>> + * current->reclaim_state, so a nested call would corrupt the outer
>> + * reclaim state. Reclaim windows are marked with PF_MEMALLOC;
>> + * reclaim_state is also checked because it is installed slightly
>> + * before PF_MEMALLOC.
>> + */
>> +static bool bpf_in_reclaim_context(void)
>> +{
>> +	return (current->flags & PF_MEMALLOC) || current->reclaim_state;
>> +}
>> +
>
> Would life improve if try_to_free_mem_cgroup_pages() didn't do that?
> If try_to_free_mem_cgroup_pages() (or some variant of it) were to
> permit nesting?
>
> 	rs = new_thing(current, &sc.reclaim_state);
> 	...
> 	set_task_reclaim_state(current, rs);
>

My understanding is that given the current restrictions on where this kfunc can
be called, this is mostly a defensive and shouldn't be firing (?). Given that,
we can probably revisit this when such reentrancy is necessary, even though I
doubt it would be the case in the future. It will at most be invoked from a wq
callback or a kthread, so should be fine.

> ?