Re: [RFC 06/10] Reclaim memory from blocked kernel stacks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Memory leak of `obj_cgroup` in the `copy_process()` error path.
- [Medium] Repopulating kernel stack pages with `NUMA_NO_NODE` silently bypasses the task's NUMA mempolicy.
--

commit 19da8486785bcd64133ab34a423835e83ba21942
Author: David Stevens <stevensd@xxxxxxxxxx>
Subject: Reclaim memory from blocked kernel stacks

This commit introduces a mechanism to reclaim unused portions of kernel
stacks for blocked tasks. It adds scheduler hooks and a new task flag
PF_RECLAIMABLE_STACK to manage safe stack reclaim and repopulation.

> diff --git a/kernel/fork.c b/kernel/fork.c
> index 6acad0038b78e..9b2cc3d01dd10 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
[ ... ]
> @@ -460,6 +462,7 @@ static int alloc_thread_stack_node(struct task_struct *tsk, int node)
>  
>  		tsk->stack_vm_area = vm_area;
>  		tsk->stack = stack;
> +		add_to_stack_shrinker(tsk, node);
>  		return 0;
>  	}

[Severity: High]
Does this leak the obj_cgroup reference in the copy_process() error path?

When dup_task_struct() completes successfully, we acquire an obj_cgroup
reference inside add_to_stack_shrinker(). However, if a subsequent step in
copy_process() fails (such as copy_mm()), the kernel jumps to the 
bad_fork_free label:

kernel/fork.c:copy_process() {
    ...
    bad_fork_free:
        WRITE_ONCE(p->__state, TASK_DEAD);
        exit_task_stack_account(p);
        put_task_stack(p);
        delayed_free_task(p);
    ...
}

Because delayed_free_task() directly frees the task without calling
__put_task_struct() or remove_from_stack_shrinker(), it seems the
obj_cgroup reference is permanently leaked, preventing the associated
mem_cgroup from being destroyed.

> diff --git a/kernel/stack_shrinker.c b/kernel/stack_shrinker.c
> new file mode 100644
> index 0000000000000..d7b1a7dfa7165
> --- /dev/null
> +++ b/kernel/stack_shrinker.c
[ ... ]
> +static bool repopulate_stack(struct task_struct *tsk, bool is_deferred,
> +			     struct llist_head *fail_list)
> +{
[ ... ]
> +	if (is_deferred) {
> +		gfp_t gfp = GFP_KERNEL_ACCOUNT | __GFP_ZERO;
[ ... ]
> +		for (; nr_allocated < num_missing_pages; nr_allocated++) {
> +			pages[nr_allocated] = alloc_pages_node_noprof(node, gfp, 0);

[Severity: Medium]
Can this silently bypass the task's NUMA mempolicy?

If a task has no specific node forced, the target node is set to NUMA_NO_NODE. 

Calling alloc_pages_node_noprof() with NUMA_NO_NODE unconditionally ignores
the task's explicit NUMA mempolicy (like MPOL_BIND or MPOL_INTERLEAVE) and
allocates from the current CPU's local node instead.

Should this branch and use alloc_pages_noprof() when the target node is 
NUMA_NO_NODE to properly respect the policy?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827232948.2520558-1-stevensd@xxxxxxxxxx?part=6