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

[Breno Leitao <leitao@debian.org>]

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.

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();
	}