On Thu 2019-10-10 14:12:01, Sergey Senozhatsky wrote: > On (10/09/19 16:26), Michal Hocko wrote: > > On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote: > > [...] > > > A generic solution would be preferable from my point of view though, > > > because otherwise each console driver owner would need to ensure that any > > > lock taken in their console.write implementation is never held while > > > memory is allocated/released. > > > > 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. 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. Deferring console work should prevent the deadlocks. Another story is allocating memory from console->write() callback. It makes the console less reliable when there is a memory contention. Preventing this would be very valuable. Best Regards, Petr
