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" <[email protected]> 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.
