Re: [syzbot] [mm?] possible deadlock in __vma_start_write

[John Ogness]

On 2025-06-04, Vlastimil Babka <vbabka@xxxxxxx> 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@xxxxxxxxxxxxx