Message-ID: <0d528748-7a55-4de8-af95-d8a197548fb7@paulmck-laptop>
Date: Tue, 21 Oct 2025 20:30:51 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Doug Anderson <dianders@...omium.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

On Tue, Oct 21, 2025 at 07:51:49PM -0700, Doug Anderson wrote:
> 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?

The tools are nothing special and again I will be pushing to get the
ones I know about fixed.  One concern is that losing the beginning of
the command line can be quite a bit more painful than losing the end.

> > 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?

That sounds eminently reasonable, thank you very much!

> 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.

We will be keeping track and setting the value we need, so I would
recommend keeping your current default.  Unless or until reviews or
experience proves otherwise.

							Thanx, Paul

Powered by blists - more mailing lists