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()
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
