Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (10/10/19 10:21), Petr Mladek wrote:
[..]
> > > Considering that console.write is called from essentially arbitrary code
> > > path IIUC then all the locks used in this path should be pretty much
> > > tail locks or console internal ones without external dependencies.
> > 
> > That's a good expectation, but I guess it's not always the case.
> > 
> > One example might be NET console - net subsystem locks, net device
> > drivers locks, maybe even some MM locks (skb allocations?).
> > 
> > But even more "commonly used" consoles sometimes break that
> > expectation. E.g. 8250
> > 
> > serial8250_console_write()
> >  serial8250_modem_status()
> >   wake_up_interruptible()
> > 
> > And so on.
> 
> I think that the only maintainable solution is to call the console
> drivers in a well defined context (kthread). We have finally opened
> doors to do this change.

Yeah, that's a pretty complex thing, I suspect. Panic flush to
netcon may deadlock if oops occurs under one of those "important
MM locks" (if any MM locks are actually involved in ATOMIC skb
allocation). If there are such MM locks, then I think flush_on_panic
issue can't be address by printing kthread or ->atomic_write callback.

> Using printk_deferred() or removing the problematic printk() is
> a short term workaround. I am not going to block such patches.
> But the final decision will be on maintainers of the affected subsystems.

Agreed.

	-ss