fs/pstore/platform.c | 4 ++++ fs/pstore/ram.c | 3 ++- include/linux/console.h | 4 ++++ include/linux/pstore.h | 2 ++ kernel/printk/nbcon.c | 7 +++++-- kernel/printk/printk.c | 6 ++++-- 6 files changed, 21 insertions(+), 5 deletions(-)
Currently, offline consoles (e.g., pstore_console backed by ramoops) inherit the system's global console_loglevel. In production environments, physical serial consoles (UARTs) are often heavily rate-limited to prevent verbose messages from causing severe execution bottlenecks. Unfortunately, this identically silences the pstore console. When a kernel panic or lockup occurs, engineers are left inspecting a crash dump that has been stripped of the verbose logs that could have identified the root cause. This series introduces CON_BYPASS_LOGLEVEL, a simple flag that allows specialized offline consoles to request unsuppressed logs directly. Patch 1 introduces the CON_BYPASS_LOGLEVEL flag. Patch 2 adopts the flag in pstore_console. Tzung-Bi Shih (2): printk: Introduce CON_BYPASS_LOGLEVEL flag pstore: Bypass loglevel suppression for pstore console fs/pstore/platform.c | 4 ++++ fs/pstore/ram.c | 3 ++- include/linux/console.h | 4 ++++ include/linux/pstore.h | 2 ++ kernel/printk/nbcon.c | 7 +++++-- kernel/printk/printk.c | 6 ++++-- 6 files changed, 21 insertions(+), 5 deletions(-) -- 2.55.0.897.gb25b4bd76c-goog
On Mon 2026-08-31 07:03:44, Tzung-Bi Shih wrote:
> Currently, offline consoles (e.g., pstore_console backed by ramoops)
> inherit the system's global console_loglevel.
>
> In production environments, physical serial consoles (UARTs) are often
> heavily rate-limited to prevent verbose messages from causing severe
> execution bottlenecks. Unfortunately, this identically silences the
> pstore console. When a kernel panic or lockup occurs, engineers are
> left inspecting a crash dump that has been stripped of the verbose logs
> that could have identified the root cause.
>
> This series introduces CON_BYPASS_LOGLEVEL, a simple flag that allows
> specialized offline consoles to request unsuppressed logs directly.
>
> Patch 1 introduces the CON_BYPASS_LOGLEVEL flag.
> Patch 2 adopts the flag in pstore_console.
I believe that a better solution for this problem would be adding
the per-console loglevel feature, see
https://lore.kernel.org/all/cover.1764272407.git.chris@chrisdown.name/
It is currently blocked by a cleanup of the console registration code,
see https://lore.kernel.org/all/20260604101459.393162-1-pmladek@suse.com/
I am going to send v5 of the console registration code cleanup soon,
hopefully later this week or the following week. It would be nice
when it gets some more review.
Best Regards,
Petr
PS: Thanks for reminder. I wanted to answer this mail the same day
when I got it. But I have to interrupted and it somehow fallen
though cracks.
On Wed, Sep 09, 2026 at 11:28:33AM +0200, Petr Mladek wrote: > On Mon 2026-08-31 07:03:44, Tzung-Bi Shih wrote: > > Currently, offline consoles (e.g., pstore_console backed by ramoops) > > inherit the system's global console_loglevel. > > > > In production environments, physical serial consoles (UARTs) are often > > heavily rate-limited to prevent verbose messages from causing severe > > execution bottlenecks. Unfortunately, this identically silences the > > pstore console. When a kernel panic or lockup occurs, engineers are > > left inspecting a crash dump that has been stripped of the verbose logs > > that could have identified the root cause. > > > > This series introduces CON_BYPASS_LOGLEVEL, a simple flag that allows > > specialized offline consoles to request unsuppressed logs directly. > > > > Patch 1 introduces the CON_BYPASS_LOGLEVEL flag. > > Patch 2 adopts the flag in pstore_console. > > I believe that a better solution for this problem would be adding > the per-console loglevel feature, see > https://lore.kernel.org/all/cover.1764272407.git.chris@chrisdown.name/ > > It is currently blocked by a cleanup of the console registration code, > see https://lore.kernel.org/all/20260604101459.393162-1-pmladek@suse.com/ > > I am going to send v5 of the console registration code cleanup soon, > hopefully later this week or the following week. It would be nice > when it gets some more review. Thanks for the context. I completely agree that the per-console loglevel is the proper long-term solution, and I understand that console registration cleanup and the larger printk reworks are massive and complex efforts. Because those foundational changes naturally take time, I was wondering if we could consider my approach as a narrow and localized exception just for offline consoles like pstore. Given that we already use LOG_FORCE_CON to bypass loglevels on a per-message basis, introducing a symmetric per-console flag like CON_BYPASS_LOGLEVEL might be an acceptable short-term solution. Would you be open to a localized flag like this in the interim, or do you strongly prefer to hold off until the full per-console loglevel architecture lands?
On 2026-09-15, Tzung-Bi Shih <tzungbi@kernel.org> wrote: >>> Currently, offline consoles (e.g., pstore_console backed by ramoops) >>> inherit the system's global console_loglevel. >>> >>> In production environments, physical serial consoles (UARTs) are often >>> heavily rate-limited to prevent verbose messages from causing severe >>> execution bottlenecks. Unfortunately, this identically silences the >>> pstore console. When a kernel panic or lockup occurs, engineers are >>> left inspecting a crash dump that has been stripped of the verbose logs >>> that could have identified the root cause. >>> >>> This series introduces CON_BYPASS_LOGLEVEL, a simple flag that allows >>> specialized offline consoles to request unsuppressed logs directly. >>> >>> Patch 1 introduces the CON_BYPASS_LOGLEVEL flag. >>> Patch 2 adopts the flag in pstore_console. >> >> I believe that a better solution for this problem would be adding >> the per-console loglevel feature, see >> https://lore.kernel.org/all/cover.1764272407.git.chris@chrisdown.name/ >> >> It is currently blocked by a cleanup of the console registration code, >> see https://lore.kernel.org/all/20260604101459.393162-1-pmladek@suse.com/ >> >> I am going to send v5 of the console registration code cleanup soon, >> hopefully later this week or the following week. It would be nice >> when it gets some more review. > > Thanks for the context. I completely agree that the per-console > loglevel is the proper long-term solution, and I understand that console > registration cleanup and the larger printk reworks are massive and > complex efforts. > > Because those foundational changes naturally take time, I was wondering > if we could consider my approach as a narrow and localized exception > just for offline consoles like pstore. > > Given that we already use LOG_FORCE_CON to bypass loglevels on a > per-message basis, introducing a symmetric per-console flag like > CON_BYPASS_LOGLEVEL might be an acceptable short-term solution. > > Would you be open to a localized flag like this in the interim, or do > you strongly prefer to hold off until the full per-console loglevel > architecture lands? I agree with Petr that we need to go with per-console loglevels here. However, we really need to prioritize our efforts to get that per-console loglevel series mainline (which means getting the cleanup series mainline first). @Petr: Maybe we can find some time in Prag to sit down together and go through the rather large queue of various printk series that are waiting to be reviewed. John
On Mon, Aug 31, 2026 at 07:03:44AM +0000, Tzung-Bi Shih wrote: > Currently, offline consoles (e.g., pstore_console backed by ramoops) > inherit the system's global console_loglevel. > > In production environments, physical serial consoles (UARTs) are often > heavily rate-limited to prevent verbose messages from causing severe > execution bottlenecks. Unfortunately, this identically silences the > pstore console. When a kernel panic or lockup occurs, engineers are > left inspecting a crash dump that has been stripped of the verbose logs > that could have identified the root cause. > > This series introduces CON_BYPASS_LOGLEVEL, a simple flag that allows > specialized offline consoles to request unsuppressed logs directly. > > Patch 1 introduces the CON_BYPASS_LOGLEVEL flag. > Patch 2 adopts the flag in pstore_console. > > Tzung-Bi Shih (2): > printk: Introduce CON_BYPASS_LOGLEVEL flag > pstore: Bypass loglevel suppression for pstore console Hi everyone, Just a gentle ping on this series. Does it make sense to you?
© 2016 - 2026 Red Hat, Inc.