[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190402022840.et7sbiamxeutbw2q@shbuild888>
Date: Tue, 2 Apr 2019 10:28:40 +0800
From: Feng Tang <feng.tang@...el.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
Hi Sergey,
Thanks for the review.
On Tue, Apr 02, 2019 at 11:14:19AM +0900, Sergey Senozhatsky wrote:
> On (04/01/19 18:48), Feng Tang wrote:
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index 1fd45a8..58d9580 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -179,7 +179,7 @@ extern void panic_flush_kmsg_end(void)
> > kmsg_dump(KMSG_DUMP_PANIC);
> > bust_spinlocks(0);
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> > }
> [..]
> > @@ -277,7 +277,7 @@ void panic(const char *fmt, ...)
> > * panic() is not being callled from OOPS.
> > */
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> [..]
> > -void console_flush_on_panic(void)
> > +void console_flush_on_panic(bool flush_all)
> > {
> > /*
> > * If someone else is holding the console lock, trylock will fail
> > @@ -2539,6 +2540,12 @@ void console_flush_on_panic(void)
> > */
> > console_trylock();
> > console_may_schedule = 0;
> > +
> > + /* User may want to see all the printk messages on panic */
> > + if (flush_all) {
> > + console_seq = log_first_seq;
> > + console_idx = log_first_idx;
> > + }
> > console_unlock();
>
> So my first thought was - let's not add a `bool flag', but instead add
> an `enum' with clear flag names, e.g. DUMP_ALL/DUMP_PENDING, etc. Something
> similar to what ftrace_dump(DUMP_ALL) does. And we already have panic_print
> bit-mask and panic_print_sys_info(), which controls what we print when in
> panic. So we can move console_flush_on_panic() to panic_print_sys_info()
> and handle different types of console_flush_on_panic() there:
>
> ---
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 0ae0d7332f12..e142faaebbcd 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -134,6 +134,11 @@ EXPORT_SYMBOL(nmi_panic);
>
> static void panic_print_sys_info(void)
> {
> + if (panic_print & PANIC_PRINT_REPLAY_LOGBUF)
> + console_flush_on_panic(DUMP_ALL);
> + else
> + console_flush_on_panic(DUMP_PENDING);
> +
> if (panic_print & PANIC_PRINT_TASK_INFO)
> show_state();
>
> @@ -277,7 +282,6 @@ void panic(const char *fmt, ...)
> * panic() is not being callled from OOPS.
> */
> debug_locks_off();
> - console_flush_on_panic();
>
> panic_print_sys_info();
>
I guess this is what my 2/2 patch exactly does :)
> ---
>
> After looking at this more - DUMP_ALL/DUMP_PENDING clearly depend
> on panic_print. So... May be we can move panic_print_sys_info() to
> printk.c, and for PANIC_PRINT_REPLAY_LOGBUF case just reset console
> seq/idx (console seq/idx are internal to printk) before we
> flush_on_panic. This way we would not need to modify
> console_flush_on_panic() prototype at all.
My thought is panic_print_sys_info() may be more related to panic, but
I'm fine with either way.
Thanks,
Feng
>
> Let's hear from people.
>
> -ss
Powered by blists - more mailing lists