public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Sreenath Vijayan <sreenath.vijayan@sony.com>
Cc: john.ogness@linutronix.de, corbet@lwn.net,
	gregkh@linuxfoundation.org, jirislaby@kernel.org,
	rdunlap@infradead.org, rostedt@goodmis.org,
	senozhatsky@chromium.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	taichi.shimoyashiki@sony.com, daniel.palmer@sony.com,
	anandakumar.balasubramaniam@sony.com
Subject: Re: [PATCH v4 2/2] tty/sysrq: Dump printk ring buffer messages via sysrq
Date: Wed, 7 Feb 2024 16:09:34 +0100	[thread overview]
Message-ID: <ZcOdLrOPiPJmCec5@alley> (raw)
In-Reply-To: <ca8dd18e434f309612c907d90e9f77c09e045b37.1706772349.git.sreenath.vijayan@sony.com>

On Thu 2024-02-01 13:12:41, Sreenath Vijayan wrote:
> When terminal is unresponsive, one cannot use dmesg to view printk
> ring buffer messages. Also, syslog services may be disabled,
> to check the messages after a reboot, especially on embedded systems.
> In this scenario, dump the printk ring buffer messages via sysrq
> by pressing sysrq+D.

I would use sysrq-R and say that it replays the kernel log on
consoles.

The word "dump" is ambiguous. People might thing that it calls
dmesg dumpers.

Also the messages would be shown on the terminal only when
console_loglevel is set to show all messages. This is done
in __handle_sysrq(). But it is not done in the workqueue
context.

Finally, the commit message should explain why workqueues are used
and what are the limitations. Something like:

<add>
The log is replayed using workqueues. The reason is that it has to
be done a safe way (in compare with panic context).

This also means that the sysrq won't have the desired effect
when the system is in so bad state that workqueues do not
make any progress.
</add>

Another reason might be that we do not want to do it in
an interrupt context. But this reason is questionable.
Many other sysrq commands do a complicate work and
print many messages as well.

Another reason is that the function need to use console_lock()
which can't be called in IRQ context. Maybe, we should use
console_trylock() instead.

The function would replay the messages only when console_trylock()
succeeds. Users could repeat the sysrq when it fails.

Idea:

Using console_trylock() actually might be more reliable than
workqueues. console_trylock() might fail repeatably when:

    + the console_lock() owner is stuck. But workqueues would fail
      in this case as well.

    + there is a flood of messages. In this case, replaying
      the log would not help much.

Another advantage is that the consoles would be flushed
in sysrq context with the manipulated console_loglevel.

Best Regards,
Petr

  parent reply	other threads:[~2024-02-07 15:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01 10:16 [PATCH v4 0/2] Add support to dump printk buffer to console via sysrq Sreenath Vijayan
2024-02-01 10:23 ` [PATCH v4 1/2] printk: Add function to dump printk buffer directly to consoles Sreenath Vijayan
2024-02-01 11:28   ` John Ogness
2024-02-07 14:43   ` Petr Mladek
2024-02-14 10:33     ` Sreenath Vijayan
2024-02-01 10:29 ` [PATCH v4 2/2] tty/sysrq: Dump printk ring buffer messages via sysrq Sreenath Vijayan
2024-02-01 11:29   ` John Ogness
2024-02-07 15:09   ` Petr Mladek [this message]
2024-02-08 10:18     ` Greg KH
2024-02-08 13:39       ` John Ogness
2024-02-14 10:40     ` Sreenath Vijayan
2024-02-14 11:12     ` Sreenath Vijayan
2024-02-26  8:01       ` Sreenath Vijayan
2024-02-26  9:28       ` John Ogness
2024-02-07 14:12 ` [PATCH v4 0/2] Add support to dump printk buffer to console " Petr Mladek
2024-02-14 10:30   ` Sreenath Vijayan

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=ZcOdLrOPiPJmCec5@alley \
    --to=pmladek@suse.com \
    --cc=anandakumar.balasubramaniam@sony.com \
    --cc=corbet@lwn.net \
    --cc=daniel.palmer@sony.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=sreenath.vijayan@sony.com \
    --cc=taichi.shimoyashiki@sony.com \
    /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