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

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

On Fri Aug 28, 2026 at 9:53 PM CEST, Shakeel Butt wrote:
> On Thu, Aug 27, 2026 at 06:36:29PM +0800, Hui Zhu wrote:
>> From: Hui Zhu <zhuhui@kylinos.cn>
>>
>> Add bpf_proactive_reclaim(), a sleepable kfunc which performs one
>> proactive reclaim pass on a given memory cgroup, similar to a write
>> to memory.reclaim but without retrying until the target is reached.
>>
>> The kfunc refuses to reclaim if the calling task is already in a
>> reclaim context, as a nested reclaim would corrupt the outer reclaim
>> state.
>>
>> Signed-off-by: Hui Zhu <zhuhui@kylinos.cn>
>> ---
>>  mm/bpf_memcontrol.c | 46 +++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/mm/bpf_memcontrol.c b/mm/bpf_memcontrol.c
>> index 716df49d7647..297ff7f05042 100644
>> --- a/mm/bpf_memcontrol.c
>> +++ b/mm/bpf_memcontrol.c
>> @@ -6,6 +6,7 @@
>>   */
>>
>>  #include <linux/memcontrol.h>
>> +#include <linux/swap.h>
>>  #include <linux/bpf.h>
>>
>>  __bpf_kfunc_start_defs();
>> @@ -159,6 +160,49 @@ __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;
>> +}
>> +
>> +/**
>> + * bpf_proactive_reclaim - proactively reclaim memory from a memory
>> + *                         cgroup
>> + * @memcg: the target memory cgroup to reclaim from
>> + * @size:  the amount of memory to reclaim, in bytes
>> + *
>> + * Trigger one proactive reclaim pass on @memcg, similar to a write to
>> + * memory.reclaim, but without retrying until @size is reached.
>> + * Must not be called with a filesystem lock held: the reclaim path
>> + * may deadlock on it via filesystem shrinkers.
>> + *
>> + * Return: The amount of memory reclaimed, in bytes, or 0 if @size is
>> + * smaller than a page or the task is already in a reclaim context.
>> + */
>> +__bpf_kfunc unsigned long bpf_proactive_reclaim(struct mem_cgroup *memcg,
>> +						unsigned long size)
>> +{
>> +	unsigned long nr_reclaimed;
>> +
>> +	if (size < PAGE_SIZE || unlikely(bpf_in_reclaim_context()))
>> +		return 0;
>
> I have been thinking about this more and more and after looking at the reasoning
> behind your check current->reclaim_state and also Sashiko's comment on NOIO/NOFS
> contexts, I am more convinced that this kfunc can not be a simple sleepable
> function. We need more than that. We need clean process context as well similar
> to the userspace poking memory.reclaim. Something like kthread or workqueue.
>
> Kumar & Andrii, is there a way to restrict a kfunc to only be called from
> special BPF threads/workqueues? Is there some similar concept in BPF world?
>

Yeah, I think the concern is valid. E.g. inode_rmdir() is sleepable but will be
problematic here, I think. My first instinct was if bpf_in_reclaim_context() +
nofs/noio save-restore might provide enough protection to let it be callable
from generic sleepable contexts, but I guess that will disable invocation of
filesystem shrinkers unconditionally.

So my suggestion would be to fix the context to BPF_PROG_TYPE_SYSCALL. There, we
should be able to init and schedule timers which poll specific state and arms wq
execution etc. It then remains invocable from sleepable async contexts (wq,
task_work) or the syscall program, all of which should be ok. Once BPF kthread
lands we can let it be callable from those threads as well, but that is for
later.

> [...]