linux-kernel - Re: [syzbot] [mm?] possible deadlock in __vma_start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84qzzzoqkw.fsf@jogness.linutronix.de>
Date: Wed, 04 Jun 2025 10:37:43 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Vlastimil Babka <vbabka@...e.cz>, syzbot
 <syzbot+23de6daeb71241d36a18@...kaller.appspotmail.com>,
 Liam.Howlett@...cle.com, akpm@...ux-foundation.org, jannh@...gle.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 lorenzo.stoakes@...cle.com, pfalcato@...e.de,
 syzkaller-bugs@...glegroups.com
Cc: Suren Baghdasaryan <surenb@...gle.com>, Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>, Peter Zijlstra <peterz@...radead.org>, Petr
 Mladek <pmladek@...e.com>
Subject: Re: [syzbot] [mm?] possible deadlock in __vma_start_write

On 2025-06-04, Vlastimil Babka <vbabka@...e.cz> wrote:
> After consulting PeterZ on IRC, he said:
>
>> so the thing complains about: vmlock <- mapping.invalidate_lock <- bcachefs_btree <- console_lock <- &helper->lock <- dev->mode_config.idr_mutex <- mm->mmap_lock <- vmlock
>
> so bcachefs is doing printk which wants console_lock, and in
> drm console a possible lock chain exists that can lead to mmap lock
>
> To me it seems all rather theoretical, but not sure where and how we could safely
> break this chain.
> Hopefully one day console_lock goes away? :)

It is a known problem that any caller holding a lock used by a
registered legacy console will result in printk() deadlocking. This is
particularly a problem with the port->lock and power management.

One workaround is to enable CONFIG_PREEMPT_RT. ;-)

A year ago (exactly) there was patch [0] providing a "threadprintk" boot
argument that would also work around this problem.

However, the only real solution is to convert the legacy consoles to
nbcon. This is work in progress.

John

[0] https://lore.kernel.org/lkml/20240603232453.33992-17-john.ogness@linutronix.de