Re: [PATCH] mm/kmemleak: report RCU-tasks quiescent states during the scan

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix: Tasks RCU stalls persist in __kmemleak_do_cleanup() and __kmemleak_scan().
- [High] Unbounded RCU critical section in kmemleak_clear() stalls Normal RCU.
--

--- Patch [1]: [PATCH] mm/kmemleak: report RCU-tasks quiescent states during the scan ---
commit 558fef0ac4a016de42546b6d38536df76b835edb
Author: Breno Leitao <leitao@debian.org>

mm/kmemleak: report RCU-tasks quiescent states during the scan

This patch replaces cond_resched() with cond_resched_tasks_rcu_qs() at various
reschedule points during the kmemleak scan. This aims to report Tasks RCU
quiescent states and prevent Tasks RCU stalls and hung tasks, since
cond_resched() by itself is not a Tasks RCU quiescent state.

> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 85f18b17e79c4..f63dfacee7ca1 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
[ ... ]
> @@ -1708,7 +1708,7 @@ static void kmemleak_cond_resched(struct kmemleak_object *object)
>  	raw_spin_unlock_irq(&kmemleak_lock);
>  
>  	rcu_read_unlock();
> -	cond_resched();
> +	cond_resched_tasks_rcu_qs();
>  	rcu_read_lock();
>  
>  	raw_spin_lock_irq(&kmemleak_lock);

[Severity: High]
This is a pre-existing issue, but modifying kmemleak_cond_resched() here
might not fully resolve the Tasks RCU stall.

kmemleak_cond_resched() is only called in __kmemleak_scan() when
need_resched() is true:

	if (need_resched())
		kmemleak_cond_resched(object);

Since Tasks RCU does not actively set the need_resched flag on running tasks
(unlike normal RCU, which uses inter-processor interrupts during a stall),
need_resched() could remain false on an otherwise idle system.

Does this mean the Tasks RCU quiescent state update is never reached,
bypassing this new logic and leaving the stall bug intact?

[ ... ]

[Severity: High]
Additionally, this is a pre-existing issue, but does __kmemleak_do_cleanup()
need a similar fix?

It still uses the bare cond_resched() in its loop:

mm/kmemleak.c:__kmemleak_do_cleanup() {
	list_for_each_entry_safe(object, tmp, &object_list, object_list) {
		...
		/* Call cond_resched() once per 64 iterations to avoid soft lockup */
		if (!(++cnt & 0x3f))
			cond_resched();
	}
}

Will this cause Tasks RCU grace periods to stall during cleanup work, just
like they were stalling during the scan?

[Severity: High]
This is another pre-existing issue, but can the unyielding loop in
kmemleak_clear() stall normal RCU?

When a privileged user writes 'clear' to /sys/kernel/debug/kmemleak, it
invokes kmemleak_clear(), which iterates over the entire object_list:

mm/kmemleak.c:kmemleak_clear() {
	rcu_read_lock();
	list_for_each_entry_rcu(object, &object_list, object_list) {
		raw_spin_lock_irq(&object->lock);
		...
		raw_spin_unlock_irq(&object->lock);
	}
	rcu_read_unlock();
}

Since this loop runs fully inside an RCU read-side critical section with no
yielding mechanisms whatsoever, could iterating millions of objects
uninterrupted exceed the 21-second RCU stall timeout and trigger normal
RCU stall warnings?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-kmemleak_rcu_task-v1-1-5b460ade777d@debian.org?part=1