init/Kconfig | 10 +++++++ init/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 92 insertions(+), 1 deletion(-)
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@chromium.org>
---
init/Kconfig | 10 +++++++
init/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index cab3ad28ca49..905b2ece4127 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1512,6 +1512,16 @@ 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 40 1021
+ help
+ At boot time, the kernel command line is logged to the console.
+ It will attempt to be wrapped at this many characters. If there
+ are more than this many non-space characters in a row, log lines
+ may exceed this ideal maximum length.
+
config INITRAMFS_PRESERVE_MTIME
bool "Preserve cpio archive mtimes in initramfs"
depends on BLK_DEV_INITRD
diff --git a/init/main.c b/init/main.c
index 07a3116811c5..0adc1575a2cb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -906,6 +906,87 @@ static void __init early_numa_node_init(void)
#endif
}
+#define KERNEL_CMDLINE_PREFIX "Kernel command line: "
+#define KERNEL_CMDLINE_PREFIX_LEN (sizeof(KERNEL_CMDLINE_PREFIX) - 1)
+#define KERNEL_CMDLINE_CONTINUATION " \\"
+#define KERNEL_CMDLINE_CONTINUATION_LEN (sizeof(KERNEL_CMDLINE_CONTINUATION) - 1)
+
+#define IDEAL_CMDLINE_LEN (CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN - \
+ KERNEL_CMDLINE_PREFIX_LEN)
+#define IDEAL_CMDLINE_SPLIT_LEN (IDEAL_CMDLINE_LEN - KERNEL_CMDLINE_CONTINUATION_LEN)
+
+/**
+ * print_kernel_cmdline() - Print the kernel cmdline with wrapping.
+ * @cmdline: The cmdline to print.
+ *
+ * Print the kernel command line, trying to wrap based on the Kconfig knob
+ * CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN.
+ *
+ * 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.
+ *
+ * Example output if CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN is 40:
+ * Kernel command line: loglevel=7 \
+ * Kernel command line: init=/sbin/init \
+ * Kernel command line: root=PARTUUID=8c3efc1a-768b-6642-8d0c-89eb782f19f0/PARTNROFF=1 \
+ * Kernel command line: rootwait ro \
+ * Kernel command line: my_quoted_arg="The \
+ * Kernel command line: quick brown fox \
+ * Kernel command line: jumps over the \
+ * Kernel command line: lazy dog."
+ */
+static void print_kernel_cmdline(const char *cmdline)
+{
+ size_t len = strlen(cmdline);
+
+ while (len > IDEAL_CMDLINE_LEN) {
+ const char *first_space;
+ const char *prev_cutoff;
+ const char *cutoff;
+ int to_print;
+ size_t used;
+
+ /* Find the last ' ' that wouldn't make the line too long */
+ prev_cutoff = NULL;
+ cutoff = cmdline;
+ while (true) {
+ cutoff = strchr(cutoff + 1, ' ');
+ if (!cutoff || cutoff - cmdline > IDEAL_CMDLINE_SPLIT_LEN)
+ break;
+ prev_cutoff = cutoff;
+ }
+ if (prev_cutoff)
+ cutoff = prev_cutoff;
+ else if (!cutoff)
+ break;
+
+ /* Find the beginning and end of the string of spaces */
+ first_space = cutoff;
+ while (first_space > cmdline && first_space[-1] == ' ')
+ first_space--;
+ to_print = first_space - cmdline;
+ while (*cutoff == ' ')
+ cutoff++;
+ used = cutoff - cmdline;
+
+ /* If the whole string is used, break and do the final printout */
+ if (len == used)
+ break;
+
+ if (to_print)
+ pr_notice("%s%.*s%s\n", KERNEL_CMDLINE_PREFIX,
+ to_print, cmdline, KERNEL_CMDLINE_CONTINUATION);
+
+ len -= used;
+ cmdline += used;
+ }
+ if (len)
+ pr_notice("%s%s\n", KERNEL_CMDLINE_PREFIX, cmdline);
+}
+
asmlinkage __visible __init __no_sanitize_address __noreturn __no_stack_protector
void start_kernel(void)
{
@@ -942,7 +1023,7 @@ void start_kernel(void)
early_numa_node_init();
boot_cpu_hotplug_init();
- pr_notice("Kernel command line: %s\n", saved_command_line);
+ print_kernel_cmdline(saved_command_line);
/* parameters may set static keys */
parse_early_param();
after_dashes = parse_args("Booting kernel",
--
2.51.0.858.gf9c4a03a3a-googOn Sun, 19 Oct 2025 10:06:14 -0700 Douglas Anderson <dianders@chromium.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. > > Add wrapping to the printout. Do we really need the wrapping? That will confuse anything which parses the output expecting a single line. And the code would presumably be much simpler if we simply chunked up the printing and spat out one really long line.
Hi, On Mon, Oct 20, 2025 at 11:51 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Sun, 19 Oct 2025 10:06:14 -0700 Douglas Anderson <dianders@chromium.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. > > > > Add wrapping to the printout. > > Do we really need the wrapping? That will confuse anything which > parses the output expecting a single line. By making the default wrapping size the same as the current truncation size, I was hoping to avoid confusion. With the default CONFIG the only case where a tool would be confused would be if they were dealing with a truncated log today and so they were already in a bad shape. The hope was also that the format was simple enough that tools could easily parse it, since each line starts with the same prefix and the initial lines all end with a " \". > And the code would presumably be much simpler if we simply chunked up > the printing and spat out one really long line. I'm not quite sure what you're suggesting. Before my changes we _do_ try to spit out one really long line, but then printk() silently truncates it for us at 1021 characters. Re-reading your suggestion, I'm not sure if you're suggesting that we improve printk() to handle lines longer than 1021 characters by chunking them up, or if you're suggesting that this code could use "pr_cont()" to chunk things up. ...or something totally different. ;-) Can you clarify? Thanks! -Doug
On Mon, 20 Oct 2025 13:00:22 -0700 Doug Anderson <dianders@chromium.org> wrote: > > And the code would presumably be much simpler if we simply chunked up > > the printing and spat out one really long line. > > I'm not quite sure what you're suggesting. Before my changes we _do_ > try to spit out one really long line, but then printk() silently > truncates it for us at 1021 characters. Re-reading your suggestion, > I'm not sure if you're suggesting that we improve printk() to handle > lines longer than 1021 characters by chunking them up, or if you're > suggesting that this code could use "pr_cont()" to chunk things up. > ...or something totally different. ;-) Can you clarify? I was suggsting the latter - emit these really long lines via repeated calls to printk().
Hi, On Tue, Oct 21, 2025 at 1:55 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Mon, 20 Oct 2025 13:00:22 -0700 Doug Anderson <dianders@chromium.org> wrote: > > > > And the code would presumably be much simpler if we simply chunked up > > > the printing and spat out one really long line. > > > > I'm not quite sure what you're suggesting. Before my changes we _do_ > > try to spit out one really long line, but then printk() silently > > truncates it for us at 1021 characters. Re-reading your suggestion, > > I'm not sure if you're suggesting that we improve printk() to handle > > lines longer than 1021 characters by chunking them up, or if you're > > suggesting that this code could use "pr_cont()" to chunk things up. > > ...or something totally different. ;-) Can you clarify? > > I was suggsting the latter - emit these really long lines via repeated > calls to printk(). OK, I coded this up. I started with a pr_notice() and after 1021 bytes I followed up with a pr_cont(). Unfortunately, this doesn't seem to work to make "one big line". The subsequent strings w/ "pr_cont()" end up on separate lines. In other words: pr_notice(first_1021_byte_str); pr_cont(second_1021_bytes_str); pr_cont(last_10_byte_str); Ends up with logs that look like: [ 0.000000] first_1021_byte_str [ 0.000000] second_1021_bytes_str [ 0.000000] last_10_byte_str ...so we end up with a worse situation than with my patches since the wrapping happens at exactly 1021 characters rather than wrapping based on spaces. I tried to dig into this a bit to make sure it wasn't just a bug in my patch. I made it wrap at 504 bytes. Now I tested something like: pr_notice(First_504_byte_str); pr_cont(Second_504_bytes_str); pr_cont(Third_504_bytes_str); pr_cont(Fourth_504_bytes_str); pr_cont(Last_10_byte_str); Now I had: [ 0.000000] First_504_byte_strSecond_504_bytes_str [ 0.000000] Third_504_bytes_strFourth_504_bytes_str [ 0.000000] Last_10_byte_str In other words pr_cont() was working properly, but it seemed to realize when the resultant string would be > 1021 characters and it started a new line for me. This further cemented in my mind that it's not a way around the 1021 character limit. For giggles, I also tried backing out my patch and just doing: -#define PRINTK_MESSAGE_MAX 2048 +#define PRINTK_MESSAGE_MAX 8192 -#define PRINTKRB_RECORD_MAX 1024 +#define PRINTKRB_RECORD_MAX 4096 When I looked at the serial console output I found success. My very long cmdline was printed out in its entirety. ...but it made "dmesg" real unhappy. :'( In fact, when I ran `dmesg` after doing this it actually fully stopped printing anything when it got to the long line. :-P Things looked OK when I looked at `/dev/kmsg` directly. ...so I ran strace on `dmesg` on my system and I found: read(3, "6,53,0,-;alternatives: applying "..., 2047) = 50 write(1, "\33[32m[ 0.000000] \33[0m\33[33malt"..., 74[ 0.000000] alternatives: applying boot alternatives ) = 74 read(3, 0xaab6c875c2d8, 2047) = -1 EINVAL (Invalid argument) close(3) = 0 In other words `dmesg` seemed to be trying to read 2047 bytes from `/dev/kmsg` and this wasn't enough to hold the output line. You can see in the kernel function devkmsg_read() that when this happens the kernel returns -EINVAL. We could _try_ to improve devkmsg_read() to be able to return partial log lines, but that violates the docs. The file `Documentation/ABI/testing/dev-kmsg` says: 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(). So tl;dr: as far as I can tell, we simply cannot put the whole cmdline (which is 2048+ on many architectures) on one line without breaking userspace. My userspace reads 2047 bytes and we'd need to return not just the cmdline but the prefix "Kernel command line:" as well as the data about time/log_level/etc. Does any of the above change your mind about my wrapping scheme? ;-) Obviously, I'd want to update my commit message with some of the research... -Doug
On Tue, 21 Oct 2025 15:57:18 -0700 Doug Anderson <dianders@chromium.org> wrote: > In other words `dmesg` seemed to be trying to read 2047 bytes from > `/dev/kmsg` and this wasn't enough to hold the output line. You can > see in the kernel function devkmsg_read() that when this happens the > kernel returns -EINVAL. > > We could _try_ to improve devkmsg_read() to be able to return partial > log lines, but that violates the docs. The file > `Documentation/ABI/testing/dev-kmsg` says: > > 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(). Well that was dumb of us. POSIX be damned. > So tl;dr: as far as I can tell, we simply cannot put the whole cmdline > (which is 2048+ on many architectures) on one line without breaking > userspace. My userspace reads 2047 bytes and we'd need to return not > just the cmdline but the prefix "Kernel command line:" as well as the > data about time/log_level/etc. > > > Does any of the above change your mind about my wrapping scheme? ;-) Yeah. > Obviously, I'd want to update my commit message with some of the > research... Sure.
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@chromium.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? thanks. -- ~Randy
Hi, On Sun, Oct 19, 2025 at 3:23 PM Randy Dunlap <rdunlap@infradead.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@chromium.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. -Doug
On 10/20/25 8:33 AM, Doug Anderson wrote: > Hi, > > On Sun, Oct 19, 2025 at 3:23 PM Randy Dunlap <rdunlap@infradead.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@chromium.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
Hi Doug,
On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@chromium.org> wrote:
> 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.
arch/s390/Kconfig:
config COMMAND_LINE_SIZE
int "Maximum size of kernel command line"
default 4096
range 896 1048576
Yummy...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
Hi, On Mon, Oct 20, 2025 at 8:42 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Doug, > > On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@chromium.org> wrote: > > 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. > > arch/s390/Kconfig: > > config COMMAND_LINE_SIZE > int "Maximum size of kernel command line" > default 4096 > range 896 1048576 > > Yummy... Wow, what are they expecting to stuff in there? An encoded initramfs or something? I kinda feel like the 1MB number isn't something anyone expects but is a number picked to effectively be "unlimited". Do you have a suggestion of what my code should do if it sees such a long cmdline? At small numbers (4K, 8K, maybe even 32K) printing the wrapped cmdline is nice. Above that, maybe it should just print something like "<cmdline truncated>" or something? -Doug Maybe after 32K or something the code should just give up?
Hi Doug,
CC s390
On Mon, 20 Oct 2025 at 18:04, Doug Anderson <dianders@chromium.org> wrote:
> On Mon, Oct 20, 2025 at 8:42 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@chromium.org> wrote:
> > > 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.
> >
> > arch/s390/Kconfig:
> >
> > config COMMAND_LINE_SIZE
> > int "Maximum size of kernel command line"
> > default 4096
> > range 896 1048576
> >
> > Yummy...
>
> Wow, what are they expecting to stuff in there? An encoded initramfs
> or something? I kinda feel like the 1MB number isn't something anyone
> expects but is a number picked to effectively be "unlimited".
Dunno, commit 622021cd6c560ce7 ("s390: make command line configurable")
lacks the "why" part.
> Do you have a suggestion of what my code should do if it sees such a
> long cmdline? At small numbers (4K, 8K, maybe even 32K) printing the
> wrapped cmdline is nice. Above that, maybe it should just print
> something like "<cmdline truncated>" or something?
I don't know, I never saw truncated kernel command lines myself.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
On Tue, Oct 21, 2025 at 09:05:48AM +0200, Geert Uytterhoeven wrote:
> On Mon, 20 Oct 2025 at 18:04, Doug Anderson <dianders@chromium.org> wrote:
> > On Mon, Oct 20, 2025 at 8:42 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@chromium.org> wrote:
> > > > 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.
> > >
> > > arch/s390/Kconfig:
> > >
> > > config COMMAND_LINE_SIZE
> > > int "Maximum size of kernel command line"
> > > default 4096
> > > range 896 1048576
> > >
> > > Yummy...
> >
> > Wow, what are they expecting to stuff in there? An encoded initramfs
> > or something? I kinda feel like the 1MB number isn't something anyone
> > expects but is a number picked to effectively be "unlimited".
>
> Dunno, commit 622021cd6c560ce7 ("s390: make command line configurable")
> lacks the "why" part.
That was just a follow-on patch of commit 5ecb2da660ab ("s390: support command
lines longer than 896 bytes") which solved the real problem with a too short
maximum command line size back then. In order to never have to deal with this
sort of problem again it was made configurable.
But I doubt that anybody will change the default ever.
Hi,
On Tue, Oct 21, 2025 at 6:16 AM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> On Tue, Oct 21, 2025 at 09:05:48AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 20 Oct 2025 at 18:04, Doug Anderson <dianders@chromium.org> wrote:
> > > On Mon, Oct 20, 2025 at 8:42 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@chromium.org> wrote:
> > > > > 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.
> > > >
> > > > arch/s390/Kconfig:
> > > >
> > > > config COMMAND_LINE_SIZE
> > > > int "Maximum size of kernel command line"
> > > > default 4096
> > > > range 896 1048576
> > > >
> > > > Yummy...
> > >
> > > Wow, what are they expecting to stuff in there? An encoded initramfs
> > > or something? I kinda feel like the 1MB number isn't something anyone
> > > expects but is a number picked to effectively be "unlimited".
> >
> > Dunno, commit 622021cd6c560ce7 ("s390: make command line configurable")
> > lacks the "why" part.
>
> That was just a follow-on patch of commit 5ecb2da660ab ("s390: support command
> lines longer than 896 bytes") which solved the real problem with a too short
> maximum command line size back then. In order to never have to deal with this
> sort of problem again it was made configurable.
>
> But I doubt that anybody will change the default ever.
OK, so my theory that 1MB cmdline is not normal / realistic / expected
sounds correct. Essentially it's just saying "we didn't want to pick a
limit". We could add a bound to what's printed if we want (4K? 16K?),
but it's maybe not critical since we wouldn't expect crazy long
cmdlines anyway.
So I guess the question is whether any of my arguments convinced
Andrew that my current wrapping logic is OK. If not, hopefully he can
clarify if either of my theories of what he meant by "chunking" were
correct and then I can send a v2. ;-)
Of course, given that the max cmdline for most architectures is
something like 2K/4K, it also might not be too horrible to just
increase the printk limit? I was assuming that would be too
controversial...
-Doug
-Doug
© 2016 - 2026 Red Hat, Inc.