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

[Shakeel Butt <shakeel.butt@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.