Re: [PATCH printk 3/3] printk: Support setting console sync mode via console=

[Petr Mladek <pmladek@suse.com>]

On Fri 2026-07-10 16:51:53, John Ogness wrote:
> Extend the console= kernel command line argument to support specifying
> sync mode at boot time. This is achieved by introducing a new "sync"
> option that can be passed within a console= cmdline argument.
> 
> For example, assuming the first serial device should be a console using
> sync mode:
> 
>    console=ttyS0,115200,sync
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Co-authored-by: Chris Down <chris@chrisdown.name>

Just for record, I guess that Chris Down is mentioned as a Co-author
because of the function find_and_remove_console_option() which seems
to be taken from
https://lore.kernel.org/all/d1cae00c839a3681759061e646f21a35b9b66613.1764272407.git.chris@chrisdown.name/

> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2567,6 +2567,81 @@ static void set_user_specified(struct console_cmdline *c, bool user_specified)
>  	console_set_on_cmdline = 1;
>  }
>  
> +/**
> + * find_and_remove_console_option - Find and remove a named option from console options string
> + * @options: The console options string (will be modified in-place)
> + * @key: The option name to find (e.g., "loglevel")
> + * @val_buf: Buffer to store the option value (if present)
> + * @val_buf_size: Size of @val_buf
> + *
> + * This function searches for a named option in a comma-separated options string
> + * (e.g., "9600n8,loglevel:3,sync"). If found, it extracts the value
> + * (the part after ':') and removes the entire option from the string.
> + *
> + * If an option does not support values, @val_buf should be NULL, in which
> + * case no value part is extracted and any user provided ':' is considered part
> + * of the option key.
> + *
> + * The function modifies @options in-place by:
> + * 1. Temporarily null-terminating option names and values during parsing
> + * 2. Restoring separators if the option isn't found
> + * 3. Removing the found option by shifting the remaining string
> + *
> + * Return: true if the option was found and removed, false otherwise
> + */
> +static bool find_and_remove_console_option(char *options, const char *key,
> +					   char *val_buf, size_t val_buf_size)
> +{
> +	bool found = false, first = true;
> +	char *option, *next = options;
> +
> +	while ((option = strsep(&next, ","))) {

Sashiko AI pointed out that add_preferred_console() is called also
by of_console_check() where the @options parameter is casted from
"const char *", see
https://sashiko.dev/#/patchset/20260710144609.194487-1-john.ogness%40linutronix.de

I believe that we should be on the safe side. Honestly, I did not
analyze it to the bottom. But the string "of_stdout_options":

  + must be '\0' terminated. So that it can't be part of a full memory dump
    of the original device tree file. It must be a dedicated memory
    entity which is accessed separately in some node tree, see
    of_find_node_opts_by_path().

  + is used only by of_console_check(). So there should not be problem
    with parallel access [*]

[*] of_console_check() is actually called from two locations:
    serial_core_add_one_port() and sprd_uart_is_console(). So there
    is some risk of parallelism.

    On the other hand, it makes sense to add the console from
    the device tree only once. And we would have bigger problems
    when add_preferred_console() is called by mode CPUs in
    parallel.

Sigh, I think that we could keep it because it should be good enough.
But I do not have 100% good feeling about it.

Second sigh, proper fix would need to either allocate a copy
or create some static buffer for options in struct console_cmdline
or so.

Or handle this a different way.

> +		char *value = NULL;
> +
> +		if (val_buf) {
> +			value = strchr(option, ':');
> +			if (value)
> +				*(value++) = '\0';
> +		}
> +
> +		if (strcmp(option, key) == 0) {
> +			found = true;
> +			if (value) {
> +				if (strlen(value) >= val_buf_size) {
> +					pr_warn("Cannot copy console option value for %s:%s: not enough space (%zu)\n",
> +						option, value, val_buf_size);
> +					found = false;
> +				} else {
> +					strscpy(val_buf, value, val_buf_size);
> +				}
> +			} else if (val_buf) {
> +				*val_buf = '\0';
> +			}
> +		}
> +
> +		if (found)
> +			break;
> +
> +		if (next)
> +			*(next - 1) = ',';
> +		if (value)
> +			*(value - 1) = ':';
> +
> +		first = false;
> +	}
> +
> +	if (found) {
> +		if (next)
> +			memmove(option, next, strlen(next) + 1);
> +		else if (first)
> +			*option = '\0';

Sashiko AI also pointed out that this would create an empty string.
For example, serial8250_console_setup() checks only whether it is NULL
and tries to read the baudate, ...

Sigh, the handling of the console parameters is yet another historic
mess which would deserve a clean up. I'll add this to my TODO
in the console registration clean up. But I think that it is beyond
the scope of this patch set.

Well, we should stay conservative and set options to NULL in this case.

> +		else
> +			*--option = '\0';
> +	}
> +
> +	return found;
> +}
> +
>  static int __add_preferred_console(const char *name, const short idx,
>  				   const char *devname, char *options,
>  				   char *brl_options, bool user_specified)

Otherwise, it looks good to me.

Best Regards,
Petr