Messages in this thread | | | Date | Wed, 8 Jul 2020 11:52:15 +0200 | From | Petr Mladek <> | Subject | Re: UART/TTY console deadlock |
| |
On Wed 2020-07-08 17:07:12, Sergey Senozhatsky wrote: > On (20/07/08 09:40), Kurt Kanzenbach wrote: > > I'm not sure how this patch will help with the situation. Because at the > > point of that THRE test the irq handler isn't registered. It's > > registered a few lines below (up->ops->setup_irq()) meaning the irq line > > has to be disabled if shared. Otherwise the kernel might detect a > > spurious irq and disables it. That's at least my understanding of the > > problem (see commit message from 54e53b2e8081 ("tty: serial: 8250: pass > > IRQ shared flag to UART ports")). > > So the only remaining approach then is to move > disable_irq_nosync()/enable_irq() out of port->lock > scope.
The ultimate solution is the offload of printk console handling to kthreads. I know that it takes ages to get it in. But it will also take ages to go around all the cyclic dependencies.
People tend to use printk() anywhere. And any lock taken by printk() is prone to cause these problems.
We have tried to go around this in the scheduler code by printk_deferred() and it was never-ending story. I believe that the port->lock related cycles are another never-ending story. And attempts to shuffle locks are always complicated and error-prone. They require deep understanding of the affected code paths. The approach with printk_deferred() has been pretty safe at least.
Another approach might be to teach lockdep to remove lock chains that were taken during the system initialization and will never happen again. Or something like this.
I still believe that this is a false positive. Console that is being initialized can't be used by printk() at the same moment. Locks taken only when the console is being initialized can't cause deadlocks when the fully initialized console is registered later.
Best Regards, Petr
| |