Message-ID: <c4848d9a-5007-414f-a95a-75f2a98bd24c@infradead.org>
Date: Mon, 20 Oct 2025 10:18:24 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Doug Anderson <dianders@...omium.org>
Cc: linux-kernel@...r.kernel.org, Andrew Chant <achant@...gle.com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Brian Gerst <brgerst@...il.com>,
 Christian Brauner <brauner@...nel.org>, Francesco Valla
 <francesco@...la.it>, Geert Uytterhoeven <geert+renesas@...der.be>,
 Guo Weikang <guoweikang.kernel@...il.com>,
 Huacai Chen <chenhuacai@...nel.org>, Jan Hendrik Farr <kernel@...rr.cc>,
 Jeff Xu <jeffxu@...omium.org>, Kees Cook <kees@...nel.org>,
 Masahiro Yamada <masahiroy@...nel.org>, Michal Koutný
 <mkoutny@...e.com>, Miguel Ojeda <ojeda@...nel.org>,
 "Mike Rapoport (Microsoft)" <rppt@...nel.org>,
 Nathan Chancellor <nathan@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Shakeel Butt <shakeel.butt@...ux.dev>,
 Tejun Heo <tj@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 "Uladzislau Rezki (Sony)" <urezki@...il.com>
Subject: Re: [PATCH] init/main.c: Wrap long kernel cmdline when printing to
 logs



On 10/20/25 8:33 AM, Doug Anderson wrote:
> Hi,
> 
> On Sun, Oct 19, 2025 at 3:23 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>>
>> Hi,
>>
>> On 10/19/25 10:06 AM, Douglas Anderson wrote:
>>> The kernel cmdline length is allowed to be longer than what printk can
>>> handle. When this happens the cmdline that's printed to the kernel
>>> ring buffer at bootup is cutoff and some kernel cmdline options are
>>> "hidden" from the logs. This undercuts the usefulness of the log
>>> message.
>>>
>>> Add wrapping to the printout. Allow wrapping to be set lower by a
>>> Kconfig knob "CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN". By default, the
>>> wrapping is set to 1021 characters, which is measured to be the
>>> current maximum that pr_notice() can handle. Anyone whose cmdline
>>> isn't being cut off today should see no difference in log output.
>>>
>>> Wrapping is based on spaces, ignoring quotes. All lines are prefixed
>>> with "Kernel command line: " and lines that are not the last line have
>>> a " \" suffix added to them. The prefix and suffix count towards the
>>> line length for wrapping purposes. The ideal length will be exceeded
>>> if no appropriate place to wrap is found.
>>>
>>> Signed-off-by: Douglas Anderson <dianders@...omium.org>
>>> ---
>>>
>>>  init/Kconfig | 10 +++++++
>>>  init/main.c  | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>  2 files changed, 92 insertions(+), 1 deletion(-)
>>
>> Is this (length) only a problem for the kernel boot command line?
>>
>> What does _printk() do with a very long string?
> 
> printk() will cut it off at ~1024 characters. The printing of the
> kernel command line is backed by pr_notice(), which is backed by
> printk(), which is where the limitation is. Yes, we could consider
> changing printk() to either remove the 1024 character limitation or
> have it do its own word wrapping, but I wouldn't expect people to be
> very receptive to that.
> 
> Thinking about increasing the maximum printk() size from 1024 to
> something bigger, I'd expect the response that people should, in the
> general case, not be printing such long strings to the kernel buffer.
> 
> Thinking about wrapping directly to printk(), I'd expect:
> * People wouldn't like the extra overhead added to every printk() call.
> * People wouldn't like the fact that there would be no obvious way to
> connect the continuation to the previous line (no way to know what the
> common prefix should be).
> * It wouldn't be obvious, in the general case, if wrapping should
> happen based on spaces.
> 
> 
> Printing the command line to the kernel log buffer is one of the very
> rare cases where:
> * There's a legitimate reason to print a (potentially) very long
> string to the kernel buffer.
> * We know that wrapping based on spaces is a reasonable thing to do.
> 
> If we want this to be something generic, we could certainly put this
> function into "lib/", sort of like how print_hex_dump() sits there.
> That function is actually a nice parallel to what we're doing here. It
> handles adding a prefix and handles intelligent wrapping that makes
> sense for the data presented.
> 
> My own preference would be to leave the code where it is and, once we
> have a second need for similar wrapping we can move the code into
> "lib/". That being said, if people think it belongs in "lib/" now I'd
> be happy to split this into two patches.

Yes, leaving it as you wrote it here is good for now IMO.

Regarding its max size (sort of ignoring the s390 MAX),
bootconfig max is 32 KB but usually not nearly that large
(Documentation/admin-guide/bootconfig.rst).

thanks.
-- 
~Randy

Powered by blists - more mailing lists