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.