From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Donghyeok Choe <d7271.choe@samsung.com>,
linux-kernel@vger.kernel.org, takakura@valinux.co.jp,
youngmin.nam@samsung.com, hajun.sung@samsung.com,
seungh.jung@samsung.com, jh1012.choi@samsung.com
Subject: Re: printk: selective deactivation of feature ignoring non panic cpu's messages
Date: Tue, 04 Mar 2025 15:05:52 +0106 [thread overview]
Message-ID: <84ikoorj53.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <Z8b-ljGnw57GpJb0@pathway>
On 2025-03-04, Petr Mladek <pmladek@suse.com> wrote:
> I mean something like:
>
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kernel/printk/printk_ringbuffer.c
> @@ -2143,7 +2143,9 @@ static bool _prb_read_valid(struct printk_ringbuffer *rb, u64 *seq,
> * But it would have the sequence number returned
> * by "prb_next_reserve_seq() - 1".
> */
> - if (this_cpu_in_panic() && ((*seq + 1) < prb_next_reserve_seq(rb)))
> + if (this_cpu_in_panic() &&
> + (!printk_debug_non_panic_cpus || legacy_allow_panic_sync) &&
> + ((*seq + 1) < prb_next_reserve_seq(rb)))
> (*seq)++;
> else
> return false;
Ah, OK. Thanks for the clarification
> OK, I propose the following changes:
>
> + rename the option to "printk_debug_non_panic_cpus"
>
> + do not skip the messages in _prb_read_valid() when this option
> is used before the non-panic CPUs are stopped.
And of course:
+ allow non-panic CPUs in panic to store messages when this option
is set
I would also keep the dump_stack_lvl() implementation as it is, even if
it could lead to interweaving of backtraces. Anyone using
printk_debug_non_panic_cpus should have CONFIG_PRINTK_CALLER enabled.
John
next prev parent reply other threads:[~2025-03-04 13:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250226031756epcas2p3674cccc82687effb40575aa5fa2956e0@epcas2p3.samsung.com>
2025-02-26 3:16 ` printk: selective deactivation of feature ignoring non panic cpu's messages Donghyeok Choe
2025-02-26 4:25 ` John Ogness
2025-02-26 13:58 ` Petr Mladek
2025-02-28 14:20 ` John Ogness
2025-03-04 2:01 ` Donghyeok Choe
2025-03-04 13:22 ` Petr Mladek
2025-03-04 13:59 ` John Ogness [this message]
2025-03-04 14:15 ` Petr Mladek
2025-03-17 5:06 ` Donghyeok Choe
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=84ikoorj53.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=d7271.choe@samsung.com \
--cc=hajun.sung@samsung.com \
--cc=jh1012.choi@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=seungh.jung@samsung.com \
--cc=takakura@valinux.co.jp \
--cc=youngmin.nam@samsung.com \
/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