Messages in this thread | | | Date | Mon, 26 Nov 2018 13:57:09 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections |
| |
On (11/23/18 12:48), Petr Mladek wrote: [..] > > This should make serial consoles re-entrant. > > So printk->console_driver_write() hopefully will not deadlock. > > Is the re-entrance safe? Some risk might be acceptable in Oops/panic > situations. It is much less acceptable for random warnings.
Good question.
But what's the alternative? A deadlock in a serial console driver; such that even panic() is not guaranteed to make through it (at least of now). debug objects are used from the code which cannot re-entrant console drivers.
bust_spinlock is called from various paths, not only panic. git grep bust_spinlocks | wc -l 62
So we already switch to re-entrant consoles (and accept the risks) in mm/fault.c, kernel/traps.c and so on. Which, I guess, makes us a little more confident, faults/traps happen often enough.
It seems, that, more or less, serial consoles are ready to handle it. UART consoles in ->write() callbacks just do a bunch of writel() [for every char + \r\n].
-ss
| |