On Tue 2016-03-22 02:25:29, Sergey Senozhatsky wrote: > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index e38579d..99c105d6 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1619,12 +1721,21 @@ asmlinkage int vprintk_emit(int facility, int level, > int printed_len = 0; > int nmi_message_lost; > bool in_sched = false; > - /* 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. > + bool sync_print = printk_sync; > + > + /* disable async printk */ > + if (in_panic) > + printk_sync = true; In each case, we should not switch the global state if we only print debug traces. Best Regards, Petr
