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

[Hui Zhu <hui.zhu@linux.dev>]

> On Sat, Sep 05, 2026 at 01:23:39PM +0200, Kumar Kartikeya Dwivedi wrote:
>> 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.
>>
> If with the current restrictions, this recursion can not happen then let's not
> add this check here. We never want recursion/reentrancy here.

Will remove it in the next version.

Best,
Hui