[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=X4Ourc0gbVnq_eQqyxDn05uV3NT2raEAKSohrN5qrwgQ@mail.gmail.com>
Date: Mon, 16 Mar 2020 17:06:55 -0700
From: Doug Anderson <dianders@...omium.org>
To: Dmitry Safonov <dima@...sta.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>, Jiri Slaby <jslaby@...e.com>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Daniel Thompson <daniel.thompson@...aro.org>,
Jason Wessel <jason.wessel@...driver.com>,
kgdb-bugreport@...ts.sourceforge.net
Subject: Re: [PATCHv2 47/50] kdb: Don't play with console_loglevel
Hi,
On Mon, Mar 16, 2020 at 7:43 AM Dmitry Safonov <dima@...sta.com> wrote:
>
> Print the stack trace with KERN_EMERG - it should be always visible.
>
> Playing with console_loglevel is a bad idea as there may be more
> messages printed than wanted. Also the stack trace might be not printed
> at all if printk() was deferred and console_loglevel was raised back
> before the trace got flushed.
>
> Unfortunately, after rebasing on commit 2277b492582d ("kdb: Fix stack
> crawling on 'running' CPUs that aren't the master"), kdb_show_stack()
> uses now kdb_dump_stack_on_cpu(), which for now won't be converted as it
> uses dump_stack() instead of show_stack().
>
> Convert for now the branch that uses show_stack() and remove
> console_loglevel exercise from that case.
>
> Cc: Daniel Thompson <daniel.thompson@...aro.org>
> Cc: Douglas Anderson <dianders@...omium.org>
> Cc: Jason Wessel <jason.wessel@...driver.com>
> Cc: kgdb-bugreport@...ts.sourceforge.net
> Signed-off-by: Dmitry Safonov <dima@...sta.com>
> ---
> kernel/debug/kdb/kdb_bt.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
Presuming that the rest of this series is deemed acceptable by those
in charge, this patch looks fine to me:
Reviewed-by: Douglas Anderson <dianders@...omium.org>
-Doug
Powered by blists - more mailing lists