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.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Chris Down <chris@chrisdown.name>
---
Documentation/admin-guide/sysctl/kernel.rst | 3 +++
kernel/printk/sysctl.c | 14 +++++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 043d5f663b7d..5ac6db03c2fb 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1096,6 +1096,9 @@ Messages without an explicit priority will be printed with this priority.
printk
======
+This sysctl is deprecated and will be removed in future. Please consider using
+``kernel.console_loglevel`` or ``kernel.default_message_loglevel`` instead.
+
The four values in printk denote: ``console_loglevel``,
``default_message_loglevel``, ``minimum_console_loglevel`` and
``default_console_loglevel`` respectively.
diff --git a/kernel/printk/sysctl.c b/kernel/printk/sysctl.c
index 034739939a61..8df4500bf3ff 100644
--- 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)
+ pr_warn_once("printk: The kernel.printk sysctl is deprecated. Consider using kernel.console_loglevel or kernel.default_message_loglevel instead.\n");
+
+ 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",
--
2.51.2Added Joel into Cc for the sysrq API changes.
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)
> + pr_warn_once("printk: The kernel.printk sysctl is deprecated. Consider using kernel.console_loglevel or kernel.default_message_loglevel instead.\n");
> +
> + 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
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
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
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
On Mon, Dec 15, 2025 at 05:06:40PM +0100, Petr Mladek wrote:
> 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").
Indeed, there is no agreed procedure. If you don't have an expected
date, then don't put it in the warn message.
>
> > 4. Should you put that date in the message?
>
> It would be useful. What about doing it in 10 years from now?
10 years seems ok to me. But since this is a guess more than a plan, I
would just not put it on the message. Up to you.
>
> > > > + 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");
I meant it more as a long line in the code. Not a long line in the
log. Like this:
pr_warn_once("printk: The kernel.printk sysctl is deprecated. Instead, use "
"kernel.console_loglevel or kernel.default_message_loglevel.\n");
Its still long, but more manageable.
Best
--
Joel Granados
Hi Joel,
On Wed, 17 Dec 2025 at 12:47, Joel Granados <joel.granados@kernel.org> wrote:
> On Mon, Dec 15, 2025 at 05:06:40PM +0100, Petr Mladek wrote:
> > On Mon 2025-12-15 10:52:28, Joel Granados wrote:
> > > On Fri, Dec 12, 2025 at 04:51:46PM +0100, Petr Mladek wrote:
> > > > > + 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");
> I meant it more as a long line in the code. Not a long line in the
> log. Like this:
>
> pr_warn_once("printk: The kernel.printk sysctl is deprecated. Instead, use "
> "kernel.console_loglevel or kernel.default_message_loglevel.\n");
>
> Its still long, but more manageable.
Please do not split long messages, as it makes it harder to find them
in the source tree.
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 Wed, 17 Dec 2025 15:33:42 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > 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");
> > I meant it more as a long line in the code. Not a long line in the
> > log. Like this:
> >
> > pr_warn_once("printk: The kernel.printk sysctl is deprecated. Instead, use "
> > "kernel.console_loglevel or kernel.default_message_loglevel.\n");
> >
> > Its still long, but more manageable.
>
> Please do not split long messages, as it makes it harder to find them
> in the source tree.
Right. Linus has stated that strings should not be split just because they
go over the column limit.
-- Steve
On Wed, Dec 17, 2025 at 11:04:43AM -0500, Steven Rostedt wrote:
> On Wed, 17 Dec 2025 15:33:42 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > > > 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");
> > > I meant it more as a long line in the code. Not a long line in the
> > > log. Like this:
> > >
> > > pr_warn_once("printk: The kernel.printk sysctl is deprecated. Instead, use "
> > > "kernel.console_loglevel or kernel.default_message_loglevel.\n");
> > >
> > > Its still long, but more manageable.
> >
> > Please do not split long messages, as it makes it harder to find them
> > in the source tree.
>
> Right. Linus has stated that strings should not be split just because they
> go over the column limit.
Oops, my bad. In that case, just leave it in one line.
pr_warn_once("printk: The kernel.printk sysctl is deprecated. Instead, use kernel.console_loglevel or kernel.default_message_loglevel.\n");
I would even try to make it shorter. Do you actually need the "kernel"
string? If it still make sense without explicitly stating the "kernel"
dir, then I would shorten it to this:
pr_warn_once("printk sysctl is deprecated. Use console_loglevel or default_message_loglevel insetad.\n");
Best
--
Joel Granados
© 2016 - 2026 Red Hat, Inc.