On Fri, Aug 22, 2025 at 03:35:41PM +0800, Gu Bowen wrote:
There are some AA deadlock issues in kmemleak, similar to the situation reported by Breno [1]. The deadlock path is as follows:
mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);
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. The proper API to use should be printk_deferred_enter()/printk_deferred_exit() [2]. Another way is to place the warn print after kmemleak is released.
[1] https://lore.kernel.org/all/20250731-kmemleak_lock-v1-1-728fd470198f@debian.... [2] https://lore.kernel.org/all/5ca375cd-4a20-4807-b897-68b289626550@redhat.com/ ====================
Signed-off-by: Gu Bowen gubowen5@huawei.com
Reviewed-by: Breno Leitao leitao@debian.org