Re: [PATCH 0/2] printk: Introduce loglevel bypass for pstore console
From: John Ogness
Date: Thu Sep 24 2026 - 11:28:57 EST
On 2026-09-15, Tzung-Bi Shih <tzungbi@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/
>>
>> It is currently blocked by a cleanup of the console registration code,
>> see https://lore.kernel.org/all/20260604101459.393162-1-pmladek@xxxxxxxx/
>>
>> 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