On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote: > On (03/21/16 16:33), Jan Kara wrote: > [..] > > > > And by calling wake_up_process() under logbuf_lock, you actually > > > > introduce > > > > recursion issues for printk_deferred() messages which are supposed to be > > > > working from under rq->lock and similar. So I think you have to keep > > > > this > > > > section outside of logbuf_lock. > > > > > > hm, in_sched (printk_deferred()) messages are printed by > > > irq work->wake_up_klogd_work_func(), not by wake_up_process() > > > from vprintk_emit(). or am I missing something? > > > > Think of following: > > > > some function > > printk() > > vprintk_emit() > > spin_lock(&logbuf_lock); > > ... > > wake_up_process() > > printk_deferred() > > vprintk_emit() -> recursion on logbuf_lock > > uh, indeed. I was more concerned about printk() calls that are > troublemakers and are already in wake_up_process() - spin_dump()s. > but yes, braking printk_deferred() in this case is a regression.
Already said any kind of printk() cannot work within logbuf_lock. :-( > thanks for pointing that out. and also thanks to Byungchul. My pleasure.
