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
next prev parent 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®