Re: [PATCH v2] mm/kmemleak: avoid soft lockup when scanning task stacks

[Catalin Marinas]

On Mon, Jun 15, 2026 at 02:29:45PM +0200, Oleg Nesterov wrote:
> On 06/12, Catalin Marinas wrote:
> >
> > Yet anther variant below, untested. Basically, it follows the
> > next_tgid() or task_seq_get_next() approach (we might as well move this
> > to a separate function to avoid excessive indentation):
> >
> > 	if (kmemleak_stack_scan) {
> > 		struct pid *pid;
> > 		int nr = 1;
> >
> > 		do {
> > 			struct task_struct *p = NULL;
> >
> > 			rcu_read_lock();
> > 			pid = find_ge_pid(nr, &init_pid_ns);
> > 			if (pid) {
> > 				nr = pid_nr(pid) + 1;
> > 				p = pid_task(pid, PIDTYPE_PID);
> > 				if (p)
> > 					get_task_struct(p);
> > 			}
> > 			rcu_read_unlock();
> 
> I don't think we need get_task_struct(p), the code above can just do
> 
> 				if (p)
> 					stack = try_get_task_stack(p);

I think we still need the task_struct around. It depends on whether
CONFIG_THREAD_INFO_IN_TASK is set but even when it is, the refcount is
still in task_struct and task->stack_refcount does not prevent freeing
of the task_struct. Then we have the !CONFIG_THREAD_INFO_IN_TASK where
try_get_task_stack() does not touch any refcount.

(or I'm misreading this code)

-- 
Catalin