On Wed 2016-03-23 10:24:43, Sergey Senozhatsky wrote:
> On (03/22/16 17:36), Petr Mladek wrote:
> > > - /* cpu currently holding logbuf_lock in this function */
> > > - static unsigned int logbuf_cpu = UINT_MAX;
> > > + bool in_panic = console_loglevel == CONSOLE_LOGLEVEL_MOTORMOUTH;
> >
> > I am just looking at the printk in NMI patchset and I will need to
> > deal with the panic state as well. I am not sure if this detection
> > is secure.
> >
> > This console level is set also by kdb_show_stack()
> > and kdb_dumpregs(). I am not sure how this kdb stuff works
> > and if it affects normal kernel but...
> >
> > Anyway, it seems that many locations detects the panic situation
> > via the variable oops_in_progress. It has another advantage
> > that it can be easily checked and we would not need any extra
> > variable here.
>
> oops_in_progress is not my favorite global. and we can't rely on it
> in async printk.
>
> in panic() we have
>
> console_verbose();
> bust_spinlocks(1); << sets to one
>
> pr_emerg("Kernel panic - not syncing: %s\n", buf);
> smp_send_stop();
>
> bust_spinlocks(0); << sets it back to zero
>
> console_flush_on_panic();
>
> there are several issues here.
> - first, panic_cpu does not see oops_in_progress right after
> bust_spinlocks(0).
> thus all printk issued from panic_cpu can go via async printk.
I though that it actually could be an advantage. console_verbore() is
called also by oops_begin() and it does not need to be fatal. But you
are right that it does not need to be the righ approach.
> - second, smp_send_stop() does not guarantee that all of the CPUs received
> STOP IPI by the time it returns. on some platforms (ARM, for instance)
> smp_send_stop()
Good to know.
> so I wanted to have in printk some panic indication that once set never
> gets cleared. my proposal was
>
> void console_panic(void)
> {
> printk_sync = false;
> }
Great idea. I think that we want to call this in panic() instead of
in vprintk_emit(). I mean that we should change the global flag only
when we are really going down.
Best Regards,
Petr
