public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox