mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: John Ogness <john.ogness@linutronix.de>, linux-kernel@vger.kernel.org
Cc: Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] printk: save loglevel before console_verbose()
Date: Fri, 16 Feb 2024 08:02:20 -0800	[thread overview]
Message-ID: <ae1c5559-4469-448c-87d3-ab458c3c8b24@oracle.com> (raw)
In-Reply-To: <87eddcsqzd.fsf@jogness.linutronix.de>

On 2/16/24 01:22, John Ogness wrote:
> On 2024-02-15, Stephen Brennan <stephen.s.brennan@oracle.com> wrote:
>> In panic() cases, console_verbose() is called, clobbering the
>> console_loglevel value. If the bug which led to the panic related to
>> printk, it can be useful to know the log level prior to the
>> console_verbose() call.
> 
> I've done a *lot* of printk debugging over the past 6 years and have
> never had a case where this would be useful (or even interesting).

Hi John,

That's fair! The point of sending it upstream is seeing if anybody else
uses this information or if I'm the only one :)

> I assume there is some rare and particular scenario you are trying to
> debug. And once you've debugged it, it is no longer useful for you
> either.
>> IMHO this does not warrant adding an extra global variable for all Linux
> users.

I've been seeing bugs (to be fair, on older kernels without the latest
printk/nbcon work, which resolves much of this) caused by excessive
printk logging & slow serial consoles. In some of these cases, the
loglevel was set low at boot but modified by an application, so it has
been nice to know what the _actual_ loglevel was at the time of the
crash, which I can use with the console baud rates and the log buffer to
get an idea for how backlogged the console was at a point in time.

But of course, the console sequence numbers can tell us how backlogged a
console is at the time of crash, and you can infer the log level to some
extent from that. So I can see this not being as valuable generally as
it is for my use case.

Thanks,
Stephen

> When Petr gets back from vacation, maybe he will have a different
> opinion.
> 
> John Ogness

  reply	other threads:[~2024-02-16 16:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16  0:51 Stephen Brennan
2024-02-16  9:22 ` John Ogness
2024-02-16 16:02   ` Stephen Brennan [this message]
2024-02-27 16:39     ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae1c5559-4469-448c-87d3-ab458c3c8b24@oracle.com \
    --to=stephen.s.brennan@oracle.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®