On Mon, Mar 14, 2016 at 11:40:55AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (03/14/16 11:30), Byungchul Park wrote: > [..] > > > so can it be > > > > > > vprintk_emit() > > > __spin_dump_deferred() > > > vprintk_deferred() > > > vprintk_emit() > > > __spin_dump_deferred() > > ^^^ > > can be caused by raw_spin_lock(logbug_lock) > > > > > vprintk_deferred() > > > > Yes, it can happen by raw_spin_lock(logbuf_lock) to print warning or error > > message. Are you worrying about an infinite recursion? > > yes. > > > 1. In the case printing warning, eventually it can fill the buffer without > > actual printing using console. > > so the worry is that the CPU that spins on __spin_dump_deferred() has IRQs > disabled and `printk_pending' bit set; but IRQ may never be enabled on this > CPU.
It's true if another cpu never release the logbug_lock. But it's another problem which current code already has and must be solved by another way. IOW, the situation where the logbug_lock is not held yet is not the case where we need to worry about whether the "IRQ work queue" works or not. > > > 2. In the case printing error, the infinite recursion can be prevented by > > debug_locks_off(). > > > > Therefore, no problem. > > -ss
