Message-ID: <CAMuHMdUg5UXRcnH18S8-QtR9y+GbnAcxEQB2EyTOgd=uSUYPTg@mail.gmail.com>
Date: Fri, 24 Oct 2025 09:50:50 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, 
	linux-s390 <linux-s390@...r.kernel.org>, Randy Dunlap <rdunlap@...radead.org>, 
	Andrew Chant <achant@...gle.com>, Heiko Carstens <hca@...ux.ibm.com>, 
	"Paul E . McKenney" <paulmck@...nel.org>, Sven Schnelle <svens@...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>, 
	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>
Subject: Re: [PATCH v3] init/main.c: Wrap long kernel cmdline when printing to logs

Hi Douglas,

On Thu, 23 Oct 2025 at 20:34, Douglas Anderson <dianders@...omium.org> 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.
>
> Setting CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN to -1 fully disables the
> wrapping logic. This means that long command lines will be truncated
> again, but this config could be set if command lines are expected to
> be long and userspace is known not to handle parsing logs with the
> wrapping.
>
> 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>

Thanks for your patch!

> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1512,6 +1512,24 @@ config BOOT_CONFIG_EMBED_FILE
>           This bootconfig will be used if there is no initrd or no other
>           bootconfig in the initrd.
>
> +config CMDLINE_LOG_WRAP_IDEAL_LEN
> +       int "Length to try to wrap the cmdline when logged at boot"
> +       default 1021
> +       range -1 1021

Apparently COMMAND_LINE_SIZE is still smaller than 1021 on several
architectures (even in asm-generic: 512).  Unfortunately only s390
still controls it through a config option, so you cannot have a
"depends on COMMAND_LINE_SIZE > 1021" here...

> +       help
> +         At boot time, the kernel command line is logged to the console.
> +         The log message will start with the prefix "Kernel command line: ".
> +         The log message will attempt to be wrapped (split into multiple log
> +         messages) at spaces based on CMDLINE_LOG_WRAP_IDEAL_LEN characters.
> +         If wrapping happens, each log message will start with the prefix and
> +         all but the last message will end with " \". Messages may exceed the
> +         ideal length if a place to wrap isn't found before the specified
> +         number of characters.
> +
> +         A value of -1 disables wrapping, though be warned that the maximum

Or zero, right?
So perhaps just use range 0 1021.

> +         length of a log message (1021 characters) may cause the cmdline to
> +         be truncated.
> +
>  config INITRAMFS_PRESERVE_MTIME
>         bool "Preserve cpio archive mtimes in initramfs"
>         depends on BLK_DEV_INITRD

> --- a/init/main.c
> +++ b/init/main.c

> +static void print_kernel_cmdline(const char *cmdline)
> +{
> +       size_t len;
> +
> +       /* Config option of -1 disables wrapping */
> +       if (CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN < 0) {

As does zero, right?

You can add a check for "COMMAND_LINE_SIZE <= 1021" here,  so the
compiler will eliminate the splitting code when it is not needed.

> +               pr_notice("%s%s\n", KERNEL_CMDLINE_PREFIX, cmdline);
> +               return;
> +       }

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists