Message-ID: <CAD=FV=WFbH6kBMcoHNwQzsay6ecQQ2sZ3qc-=XTboFXK+RSspA@mail.gmail.com>
Date: Tue, 21 Oct 2025 19:51:49 -0700
From: Doug Anderson <dianders@...omium.org>
To: paulmck@...nel.org
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, 
	linux-s390 <linux-s390@...r.kernel.org>, Andrew Chant <achant@...gle.com>, 
	Sven Schnelle <svens@...ux.ibm.com>, Randy Dunlap <rdunlap@...radead.org>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Heiko Carstens <hca@...ux.ibm.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Brian Gerst <brgerst@...il.com>, 
	Christian Brauner <brauner@...nel.org>, Francesco Valla <francesco@...la.it>, 
	Guo Weikang <guoweikang.kernel@...il.com>, Huacai Chen <chenhuacai@...nel.org>, 
	Ingo Molnar <mingo@...nel.org>, Jan Hendrik Farr <kernel@...rr.cc>, Jeff Xu <jeffxu@...omium.org>, 
	Kees Cook <kees@...nel.org>, Masahiro Yamada <masahiroy@...nel.org>, 
	"Masami Hiramatsu (Google)" <mhiramat@...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>
Subject: Re: [PATCH v2] init/main.c: Wrap long kernel cmdline when printing to logs

Hi,

On Tue, Oct 21, 2025 at 7:16 PM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> On Tue, Oct 21, 2025 at 05:39:48PM -0700, 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.
> >
> > Specifically, grepping for COMMAND_LINE_SIZE shows that 2048 is common
> > and some architectures even define it as 4096. s390 allows a
> > CONFIG-based maximum up to 1MB (though it's not expected that anyone
> > will go over the default max of 4096 [1]).
> >
> > The maximum message pr_notice() seems to be able to handle (based on
> > experiment) is 1021 characters. This appears to be based on the
> > current value of PRINTKRB_RECORD_MAX as 1024 and the fact that
> > pr_notice() spends 2 characters on the loglevel prefix and we have a
> > '\n' at the end.
> >
> > While it would be possible to increase the limits of printk() (and
> > therefore pr_notice()) somewhat, it doesn't appear possible to
> > increase it enough to fully include a 2048-character cmdline without
> > breaking userspace. Specifically on at least two tested userspaces
> > (ChromeOS plus the Debian-based distro I'm typing this message on) the
> > `dmesg` tool reads lines from `/dev/kmsg` in 2047-byte chunks. As per
> > `Documentation/ABI/testing/dev-kmsg`:
> >
> >   Every read() from the opened device node receives one record
> >   of the kernel's printk buffer.
> >   ...
> >   Messages in the record ring buffer get overwritten as whole,
> >   there are never partial messages received by read().
> >
> > We simply can't fit a 2048-byte cmdline plus the "Kernel command
> > line:" prefix plus info about time/log_level/etc in a 2047-byte read.
> >
> > The above means that if we want to avoid the truncation we need to do
> > some type of wrapping of the cmdline when printing.
> >
> > Add wrapping to the printout of the kernel command line. By default,
> > the wrapping is set to 1021 characters to avoid breaking anyone, but
> > allow wrapping to be set lower by a Kconfig knob
> > "CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN". Any tools that are correctly
> > parsing the cmdline today (because it is less than 1021 characters)
> > will see no difference in their behavior. The format of wrapped output
> > is designed to be matched by anyone using "grep" to search for the
> > cmdline and also to be easy for tools to handle. Anyone who is sure
> > their tools (if any) handle the wrapped format can choose a lower
> > wrapping value and have prettier 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.
> >
> > The wrapping function added here is fairly generic and could be made a
> > library function (somewhat like print_hex_dump()) if it's needed
> > elsewhere in the kernel. However, having printk() directly incorporate
> > this wrapping would be unlikely to be a good idea since it would break
> > printouts into more than one record without any obvious common line
> > prefix to tie lines together. It would also be extra overhead when, in
> > general, kernel log message should simply be kept smaller than 1021
> > bytes. For some discussion on this topic, see responses to the v1
> > posting of this patch [2].
> >
> > [1] https://lore.kernel.org/r/20251021131633.26700Dd6-hca@linux.ibm.com
> > [2] https://lore.kernel.org/r/CAD=FV=VNyt1zG_8pS64wgV8VkZWiWJymnZ-XCfkrfaAhhFSKcA@mail.gmail.com
> >
> > Signed-off-by: Douglas Anderson <dianders@...omium.org>
>
> Nice!!!
>
> However, there is tooling that will choke on the line-wrapping.  :-(

Ah, so you're saying that you know of a tool that will behave better
if an overflowing cmdline is truncated (like the current behavior)
instead of an overflowing cmdline suddenly starting to wrap. OK,
that's fair. Any chance you could provide any more details about the
tool?


> So would it be possible to have a Kconfig option (or a special value for
> your new CMDLINE_LOG_WRAP_IDEAL_LEN Kconfig option) that preserves the
> old behavior?  (Yes, I am of course looking into making things line-wrap
> tolerant here, but...)

Seems like a valid request. I'd rather not add yet another Kconfig
option, but how about if I allow CMDLINE_LOG_WRAP_IDEAL_LEN to go from
-1 to 1021. Any time that the value is a nonnegative value less than
the length of the prefix ("Kernel command line: ") we'll basically
just always wrap at the first space. If the config is the special
value of -1 then it will totally disable the new behavior. Does that
seem reasonable?

Do you have any preference about what the default should be? If the
tool you're aware of is something that's common and lots of people use
it, then it seems like -1 should be the default. If your tool is
something that's just on a special / custom linux distro then maybe
you'd be OK with the default of 1021.

-Doug

Powered by blists - more mailing lists