linux-kernel - Re: [PATCH v3] printk: allow direct console printing to be enabled always

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YrCnJTIB/7MexV3K@alley>
Date:   Mon, 20 Jun 2022 18:58:13 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v3] printk: allow direct console printing to be enabled
 always

On Mon 2022-06-20 01:33:02, Jason A. Donenfeld wrote:
> In 5.19, there are some changes in printk message ordering /
> interleaving which leads to confusion. The most obvious (and benign)
> example appears on system boot, in which the "Run /init as init process"
> message gets intermixed with the messages that init actually writes() to
> stdout. For example, here's a snippet from build.wireguard.com:
> 
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -35,6 +35,18 @@ config PRINTK_CALLER
>  	  no option to enable/disable at the kernel command line parameter or
>  	  sysfs interface.
>  
> +config PRINTK_DIRECT
> +	bool "Attempt to flush printk output immediately"
> +	depends on PRINTK
> +	help
> +	  Rather than using kthreads for printk output, always attempt to write
> +	  to the console immediately. This has performance implications, but
> +	  will result in a more faithful ordering and interleaving with other
> +	  processes writing to the console.
> +
> +	  Say N here unless you really need this. This may also be controlled
> +	  at boot time with printk.direct=0/1.
> +

I am fine with the patch except for the config option. Is there
any particular reason why we need it, please?

We should be careful to add new build options in general because they
make building the kernel more complicated. People need to understand
what each option is about and what they want.

Kernel parameters are less intrusive. People need to care about
it only when they need some special behavior. And everyone has
its own default command line anyway. For example, I always use
ignore_loglevel.

Best Regards,
Petr