Hello,
On (09/02/16 17:15), Petr Mladek wrote:
[..]
> > I meant that this thing
> >
> > local_irq_save() // or preempt_disable()
> > ...
> > if (console_trylock())
> > console_unlock();
> > ...
> > local_irq_restore() // or preempt_enable()
>
> I see.
>
> > can easily lockup the system if console_trylock() was successful and there
> > are enough messages to print. printk_kthread can't help, because here we
> > basically enforce the `old' behavior. we have async printk, but not async
> > console output. tweaking console_unlock() to offload the actual printing
> > loop
> > to printk_kthread would make the entire console output async:
> >
> > static void console_sync_flush_and_unlock(void)
> > {
> > for (;;) {
> > ...
> > call_console_drivers();
> > ...
> > }
> > }
> >
> > void console_unlock(void)
> > {
> > if (!MOTORMOUTH && can_printk_async()) {
> > up();
> > wake_up_process(printk_kthread);
> > return;
> > }
> > console_sync_flush_and_unlock();
> > }
>
> Something like this would make sense. But I would do it in a separate
> patch(set). We need to go through all console_unlock() callers and
> make sure that they are fine with the potential async behavior.
> I would not complicate the async printk patchset by this.
sure. just added one more item to the list.
-ss
