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: <aUAyEHYtIN1CGtYL@pathway>
Date: Mon, 15 Dec 2025 17:06:40 +0100
From: Petr Mladek <pmladek@...e.com>
To: Joel Granados <joel.granados@...nel.org>
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 Mon 2025-12-15 10:52:28, Joel Granados wrote:
> 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.
> > > 
> > > - 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
> > > @@ -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?

I hope so.

> 2. Shouldn't you warn on read as well (if it is going to be completely
>    removed).

Makes perfect sense. We should.

> 3. Is there a plan for when this will be completely removed? Is there a
>    date?

Honeslty, I do not have much experience with removing such API.
I am not sure how aggressive we could be.

For example, it seems that it is going to take 15 years to obsolete
automounting of tracefs in debugfs. But they added the warning
10 years after adding tracefs, see commit 9ba817fb7c6afd3
("tracing: Deprecate auto-mounting tracefs in debugfs").

> 4. Should you put that date in the message?

It would be useful. What about doing it in 10 years from now?

> > > +		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?

OK, what about the following?

	pr_warn_once("printk: The kernel.printk sysctl is deprecated and will be removed in 2036.\n");
	pr_warn_once("printk: Use kernel.console_loglevel or kernel.default_message_loglevel instead.\n");

> > 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.

Thanks for checking and feedback.

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ