On 8/1/25 6:33 PM, Andrew Morton wrote:
On Wed, 30 Jul 2025 17:49:14 +0800 Gu Bowen gubowen5@huawei.com wrote:
kmemleak_scan_thread() invokes scan_block() which may invoke a nomal printk() to print warning message. This can cause a deadlock in the scenario reported below:
CPU0 CPU1 ---- ----
lock(kmemleak_lock); lock(&port->lock); lock(kmemleak_lock); lock(console_owner);
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.
Our syztester report the following lockdep error:
...
index 4801751cb6b6..d322897a1de1 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -390,9 +390,11 @@ static struct kmemleak_object *lookup_object(unsigned long ptr, int alias) else if (object->pointer == ptr || alias) return object; else {
__printk_safe_enter(); kmemleak_warn("Found object by alias at 0x%08lx\n", ptr); dump_object_info(object);
} }__printk_safe_exit(); break;
Thanks.
There have been a few kmemleak locking fixes lately.
I believe this fix is independent from the previous ones:
https://lkml.kernel.org/r/20250731-kmemleak_lock-v1-1-728fd470198f@debian.or... https://lkml.kernel.org/r/20250728190248.605750-1-longman@redhat.com
But can people please check?
I believe that __printk_safe_enter()/_printk_safe_exit() are for printk internal use only. The proper API to use should be printk_deferred_enter()/printk_deferred_exit() if we want to deferred the printing. Since kmemleak_lock will have been acquired with irq disabled, it meets the condition that printk_deferred_*() APIs can be used.
Cheers, Longman