From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Chris Down <chris@chrisdown.name>
Cc: linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
kernel-team@fb.com
Subject: Re: [RFC PATCH v2] printk: console: Allow each console to have its own loglevel
Date: Sat, 21 May 2022 20:51:54 +0200 [thread overview]
Message-ID: <Yok0yjx0aKvlgoIL@kroah.com> (raw)
In-Reply-To: <YoeQLxhDeIk4VSmx@chrisdown.name>
On Fri, May 20, 2022 at 01:57:19PM +0100, Chris Down wrote:
> [Once the goals of this patch are generally agreed upon, it can be split
> out further with more detailed changelogs if desired.]
>
> Consoles can have vastly different latencies and throughputs. For
> example, writing a message to the serial console can take on the order
> of tens of milliseconds to get the UART to successfully write a message.
> While this might be fine for a single, one-off message, this can cause
> significant application-level stalls in situations where the kernel
> writes large amounts of information to the console.
>
> This means that while you might want to send at least INFO level
> messages to (for example) netconsole, which is relatively fast, you may
> only want to send at least WARN level messages to the serial console.
> Such an implementation would permit debugging using the serial console
> in cases that netconsole doesn't receive messages during particularly
> bad system issues, while still keeping the noise low enough to avoid
> inducing latency in userspace applications. This patch adds such an
> interface, extending the existing console loglevel controls to allow
> each console to have its own loglevel.
>
> One can't just disable the serial console, because one may actually need
> it in situations where the machine is in a bad enough state that nothing
> is received on netconsole. One also can't just bump the loglevel at
> runtime after the issue, because usually the machine is already so
> wedged by this point that it isn't responsive to such requests.
>
> In terms of technical implementation, this patch embeds a device pointer
> in the console struct, and registers each console using it so we can
> expose attributes in sysfs.
>
> The lifecycle of this classdev looks like this on registration:
>
> register_console(con)/printk_late_init()
> console_register_device(con)
> device_initialize(con->classdev) # refcount++
> device_add(con->classdev) # refcount++
>
> At stable state, the refcount is two.
>
> Console unregistration looks like this:
>
> [con->classdev refcount drops to 0]
> console_classdev_release(con->classdev)
> kfree(con->classdev)
>
> unregister_console(con)
> device_unregister(con->classdev)
> device_del(con->classdev) # refcount--
> device_remove_class_symlinks()
> kernfs_remove_by_name_ns()
> kernfs_drain()
> kernfs_drain_open_files() # wait for close()
> put_device(con->classdev) # refcount--
>
> We also deprecate the kernel.printk sysctl as it doesn't know about
> per-console loglevels, and is generally pretty confusing.
>
> For information on the precedence and application of the new controls,
> see Documentation/ABI/testing/sysfs-class-console and
> Documentation/admin-guide/per-console-loglevel.rst.
>
> Signed-off-by: Chris Down <chris@chrisdown.name>
> ---
> Documentation/ABI/testing/sysfs-class-console | 50 +++
> .../admin-guide/kernel-parameters.txt | 18 +-
> .../admin-guide/per-console-loglevel.rst | 116 ++++++
> Documentation/admin-guide/serial-console.rst | 17 +-
> Documentation/core-api/printk-basics.rst | 34 +-
> Documentation/networking/netconsole.rst | 17 +
> MAINTAINERS | 3 +
> include/linux/console.h | 23 ++
> include/linux/kern_levels.h | 2 +
> init/main.c | 2 +-
> kernel/printk/console_cmdline.h | 2 +
> kernel/printk/printk.c | 352 ++++++++++++++++--
> kernel/printk/sysctl.c | 95 ++++-
> 13 files changed, 680 insertions(+), 51 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-console
> create mode 100644 Documentation/admin-guide/per-console-loglevel.rst
You forgot what changed from v1 :(
Anyway, the driver model interaction looks good to me, nice work, no
objections at all.
gre gk-h
next prev parent reply other threads:[~2022-05-21 18:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 12:57 [RFC PATCH v2] printk: console: Allow each console to have its own loglevel Chris Down
2022-05-20 16:06 ` Rik van Riel
2022-07-07 14:38 ` Petr Mladek
2022-07-13 14:32 ` Chris Down
2022-05-21 18:51 ` Greg Kroah-Hartman [this message]
2022-05-21 19:23 ` Chris Down
2022-05-23 13:09 ` Vincent Whitchurch
2022-05-23 14:24 ` Chris Down
2022-06-16 15:57 ` Chris Down
2022-07-08 15:23 ` design: was: " Petr Mladek
2022-07-08 19:04 ` John Ogness
2022-07-11 8:32 ` Petr Mladek
2022-07-11 10:17 ` Sergey Senozhatsky
2022-07-13 14:50 ` Chris Down
2022-07-13 14:49 ` Chris Down
2022-07-14 15:44 ` Petr Mladek
2022-07-15 12:49 ` Petr Mladek
2022-07-15 13:00 ` Chris Down
2022-07-19 12:11 ` Chris Down
2022-07-19 13:00 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yok0yjx0aKvlgoIL@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=chris@chrisdown.name \
--cc=geert@linux-m68k.org \
--cc=john.ogness@linutronix.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.