[Ksummit-discuss] [TECH TOPIC] asynchronous printk
Sergey Senozhatsky
sergey.senozhatsky.work at gmail.com
Tue Jul 19 07:46:32 UTC 2016
On (07/19/16 09:38), Hannes Reinecke wrote:
[..]
> > yes, panic() must be in sync printk mode. but we do it a
> > bit differently: console_verbose() forces printk to switch
> > to sync mode.
> >
> > so panic() goes like this:
> >
> > panic()
> > {
> > console_verbose(); # switch to sync printk. forever.
> > bust_spinlocks();
> > pr_emerg("Kernel panic - not syncing...");
> >
> > ....
> > debug_locks_off();
> > console_flush_on_panic(); # flushes kernel log_bug in
> > # sync mode
> >
> > // the rest of panic()
> >
> > }
> >
> > -ss
> >
> but this is precisely what I meant by priority inversion:
> If there are lots of messages in the printk buffer we might not be
> _able_ to print out everything as the machine died before the entire
> printk buffer could be printed.
why would it die? the same CPU that panics the system flushes the
log_buf in sync mode. console_flush_on_panic() is invoked after
panic_smp_send_stop(), which is supposed to IPI_STOP other CPUs on the
system, but before panic() reboots the system (if it must reboot it).
and it does not really care whether console_sem is available, it goes
to console_unlock() in any case
void console_flush_on_panic(void)
{
/*
* If someone else is holding the console lock, trylock will fail
* and may_schedule may be set. Ignore and proceed to unlock so
* that messages are flushed out. As this can be called from any
* context and we don't want to get preempted while flushing,
* ensure may_schedule is cleared.
*/
console_trylock();
console_may_schedule = 0;
console_unlock();
}
so why would the system die before we console_unlock()?
-ss
More information about the Ksummit-discuss
mailing list