linux-kernel - Re: [PATCH v8 20/21] printk: Deprecate the kernel.printk sysctl interface

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: <cgllbp7fdjyk6lcelxpooxkwir6bp4qgvavapdvy4i2ozn4kt5@ufikgdkym7jb>
Date: Mon, 15 Dec 2025 10:52:28 +0100
From: Joel Granados <joel.granados@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Chris Down <chris@...isdown.name>, linux-kernel@...r.kernel.org, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Steven Rostedt <rostedt@...dmis.org>, John Ogness <john.ogness@...utronix.de>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Tony Lindgren <tony.lindgren@...ux.intel.com>, 
	kernel-team@...com
Subject: Re: [PATCH v8 20/21] printk: Deprecate the kernel.printk sysctl
 interface

On Fri, Dec 12, 2025 at 04:51:46PM +0100, Petr Mladek wrote:
> Added Joel into Cc for the sysrq API changes.
Thx. I have just two comments (inline)

> 
> On Fri 2025-11-28 03:44:33, Chris Down wrote:
> > The kernel.printk sysctl interface is deprecated in favour of more
> > granular and clearer sysctl interfaces for controlling loglevels, namely
> > kernel.console_loglevel and kernel.default_message_loglevel.
> > 
> > kernel.printk has a number of fairly significant usability problems:
> > 
> > - It takes four values in a specific order, which is not intuitive.
> >   Speaking from personal experience, even people working on printk
> >   sometimes need to look up the order of these values, which doesn't
> >   suggest much in the way of perspicuity.
> > - There is no validation on the input values, so users can set them to
> >   invalid or nonsensical values without receiving any errors or
> >   warnings. This can lead to unpredictable behaviour.
> > - One of the four values, default_console_loglevel, is not used in the
> >   kernel (see below), making it redundant and potentially confusing.
> > - Overall, the interface is complex, hard to understand, and combines
> >   multiple controls into a single sysctl, which is not ideal. It should
> >   be separated into distinct controls for clarity.
> > 
> > Setting kernel.printk now calls printk_sysctl_deprecated, which emits a
> > pr_warn. The warning informs users about the deprecation and suggests
> > using the new sysctl interfaces instead.
> > 
> > By deprecating kernel.printk, we aim to:
> > 
> > - Encourage users to adopt the new, dedicated sysctl interfaces
> >   (kernel.console_loglevel and kernel.default_message_loglevel), which
> >   are more straightforward and easier to understand.
> > - Improve input validation and error handling, ensuring that users
> >   receive appropriate feedback when setting invalid values.
> > - Simplify the configuration of loglevels by exposing only the controls
> >   that are necessary and relevant.
> > 
> > --- a/kernel/printk/sysctl.c
> > +++ b/kernel/printk/sysctl.c
> > @@ -7,6 +7,7 @@
> >  #include <linux/printk.h>
> >  #include <linux/capability.h>
> >  #include <linux/ratelimit.h>
> > +#include <linux/console.h>
> >  #include "internal.h"
> >  
> >  static const int ten_thousand = 10000;
> > @@ -67,13 +68,24 @@ static int proc_dointvec_console_loglevel(const struct ctl_table *table,
> >  			       do_proc_dointvec_console_loglevel, NULL);
> >  }
> >  
> > +static int proc_dointvec_printk_deprecated(const struct ctl_table *table, int write,
> > +					   void *buffer, size_t *lenp, loff_t *ppos)
> > +{
> > +	int res = proc_dointvec(table, write, buffer, lenp, ppos);
> > +
> > +	if (write)
This would print out a warning when the user writes to the file.
I have some questions here:
1. Is this sysctl to be completely removed in the future?
2. Shouldn't you warn on read as well (if it is going to be completely
   removed).
3. Is there a plan for when this will be completely removed? Is there a
   date?
4. Should you put that date in the message?


> > +		pr_warn_once("printk: The kernel.printk sysctl is deprecated. Consider using kernel.console_loglevel or kernel.default_message_loglevel instead.\n");
Line seems very long. cut it in two?

> > +
> > +	return res;
> > +}
> > +
> >  static const struct ctl_table printk_sysctls[] = {
> >  	{
> >  		.procname	= "printk",
> >  		.data		= &console_loglevel,
> >  		.maxlen		= 4*sizeof(int),
> >  		.mode		= 0644,
> > -		.proc_handler	= proc_dointvec,
> > +		.proc_handler	= proc_dointvec_printk_deprecated,
> >  	},
> >  	{
> >  		.procname	= "printk_ratelimit",
> 
> These changes work because the sysctl API changes were backward
> compatible. But it would be nice to follow the new parameter names,
> ...
> 
> I propose to do:
> 
>    + renamed @write to @dir
>    + use SYSCTL_USER_TO_KERN(dir) macro
This looks good to me.

> 
> I mean to do the following changes on top of this patch:
> 
> --- a/kernel/printk/sysctl.c
> +++ b/kernel/printk/sysctl.c
> @@ -73,12 +73,12 @@ static int proc_dointvec_console_loglevel(const struct ctl_table *table,
>  			       do_proc_dointvec_console_loglevel);
>  }
>  
> -static int proc_dointvec_printk_deprecated(const struct ctl_table *table, int write,
> +static int proc_dointvec_printk_deprecated(const struct ctl_table *table, int dir,
>  					   void *buffer, size_t *lenp, loff_t *ppos)
>  {
> -	int res = proc_dointvec(table, write, buffer, lenp, ppos);
> +	int res = proc_dointvec(table, dir, buffer, lenp, ppos);
>  
> -	if (write)
> +	if (SYSCTL_USER_TO_KERN(dir))
>  		pr_warn_once("printk: The kernel.printk sysctl is deprecated. Consider using kernel.console_loglevel or kernel.default_message_loglevel instead.\n");
>  
>  	return res;
> 
> 
> Best Regards,
> Petr

-- 

Joel Granados

Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)