On Tue 2018-01-16 14:16:22, Sergey Senozhatsky wrote: > On (01/15/18 09:51), Petr Mladek wrote: > > On Sat 2018-01-13 16:31:00, Sergey Senozhatsky wrote: > > > On (01/12/18 13:55), Petr Mladek wrote: > > > [..] > > > > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > > > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > > > > PREEMPT kernels than !PREEMPT ones. > > > > > > > > I would say that the patch improves also console_unlock() but only in > > > > non-preemttive context. > > > > > > > > By other words, it makes console_unlock() finite in preemptible context > > > > (limited by buffer size). It might still be unlimited in > > > > non-preemtible context. > > > > > > could you elaborate a bit? > > > > Ah, I am sorry, I swapped the conditions. I meant that > > console_unlock() is finite in non-preemptible context. > > by the way. just for the record, > > probably there is a way for us to have a task printing more than > O(logbuf) even in non-preemptible context. > > CPU0 > > vprintk_emit() > preempt_disable() > console_unlock() > { > for (;;) { > printk_safe_enter_irqsave() > call_console_drivers(); > printk_safe_exit_irqrestore() > > << IRQ >> > dump_stack() > printk()->log_store() > .... > printk()->log_store() > << iret >> > } > } > preempt_enable()
Great catch! And good to know about it when designing further improvements. Best Regards, Petr