Re: [PATCH v5] mm: Fix possible deadlock in kmemleak

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Sep 19, 2025 at 03:37:27AM -0700, Breno Leitao wrote:
> On Fri, Aug 22, 2025 at 03:35:41PM +0800, Gu Bowen wrote:
> > To solve this problem, switch to printk_safe mode before printing warning
> > message, this will redirect all printk()-s to a special per-CPU buffer,
> > which will be flushed later from a safe context (irq work), and this
> > deadlock problem can be avoided.
> 
> I am still thinking about this problem, given I got another deadlock
> issue that I was not able to debug further given I do not have the
> crashdump.

Do you have some kernel log? I thought we covered all cases in
kmemleak.c (well, might have missed some).

> Should we have a wrapper around raw_spin_lock_irqsave(kmemleak_lock,
> flags), that would defer printk at all? 
> 
> Then, we can simply replace the raw_spin_lock_irqsave() by the helper,
> avoiding spreading these printk_deferred_enter() in the kmemleak code.
> 
> For instance, something as this completely untested code, just to show
> the idea.
> 
> 	void kmemleak_lock(unsigned long *flags) {
> 		printk_deferred_enter();
> 		raw_spin_lock_irqsave(&kmemleak_lock, flags);
> 	}
> 
> 	void kmemleak_lock(unsigned long flags) {
> 		raw_spin_unlock_irqrestore(&kmemleak_lock, flags);
> 		printk_deferred_exit();
> 	}

The way we added the printk deferring recently is around the actual
printk() calls. Given that you can't get an interrupt under
raw_spin_lock_irqsave(), I don't think printk_deferred_exit() would
trigger a console flush. So we could simply add them around those
kmemleak_warn() or pr_*() calls rather than together with the spinlocks.
But we do need to be able to reproduce the problem and show that any
potential patch fixes it.

-- 
Catalin