Messages in this thread | | | Date | Tue, 22 Mar 2016 11:18:24 +0900 | From | Byungchul Park <> | Subject | Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async |
| |
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.
| |