From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, "J. Avila" <elavila@google.com>
Subject: Re: [PATCH] printk: avoid prb_first_valid_seq() where possible
Date: Wed, 10 Feb 2021 19:32:10 +0106 [thread overview]
Message-ID: <874kij4w59.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <YCLKvCNJwabVavAP@alley>
On 2021-02-09, Petr Mladek <pmladek@suse.com> wrote:
>> @@ -1629,9 +1631,13 @@ int do_syslog(int type, char __user *buf, int len, int source)
>> /* Number of chars in the log buffer */
>> case SYSLOG_ACTION_SIZE_UNREAD:
>> logbuf_lock_irq();
>> - if (syslog_seq < prb_first_valid_seq(prb)) {
>> - /* messages are gone, move to first one */
>> - syslog_seq = prb_first_valid_seq(prb);
>> + if (prb_read_valid_info(prb, syslog_seq, &info, NULL)) {
>> + if (info.seq != syslog_seq) {
>> + /* messages are gone, move to first one */
>> + syslog_seq = info.seq;
>> + syslog_partial = 0;
>> + }
>> + } else {
>> syslog_partial = 0;
>
> I am scratching my head when prb_read_valid_info(prb,
> syslog_seq, &info, NULL)) might fail.
It can fail because the descriptor has been invalidated/recycled by
writers and perhaps there is no valid record that has yet come after it.
> It might fail when syslog_seq points to the next message
> after the last valid one. In this case, we could return
> immediately (after releasing the lock) because there are
> zero unread messages.
Yes, we could just return 0 in this case. If we are returning and not
modifying @syslog_seq, then there is no need to reset
@syslog_partial. At some point a reader will notice that the record is
gone and reset @syslog_partial accordingly.
> Anyway, syslog_partial must be zero in this case. syslog_seq
> should stay when the last read was partial. And there should
> always be at least one valid message in the log buffer
> be design.
A record can be invalidated at any time. It is a normal case that a
re-read of a record (to get the rest of the partial) can lead to the
record no longer being available.
> IMHO, it would deserve a comment and maybe even a warning.
I don't think we need a warning. It is something that can happen and it
is not a problem.
> What about something like?
>
> /* Number of chars in the log buffer */
> case SYSLOG_ACTION_SIZE_UNREAD:
> logbuf_lock_irq();
> if (!prb_read_valid_info(prb, syslog_seq, &info, NULL)) {
> /* No unread message */
> if (syslog_partial) {
> /* This should never happen. */
> pr_err_once("Unable to read any message even when the last syslog read was partial: %zu", syslog_partial);
> syslog_partial = 0;
> }
> logbuf_unlock_irq();
> return 0;
> }
I recommend changing your suggestion to:
> if (!prb_read_valid_info(prb, syslog_seq, &info, NULL)) {
> /*
> * No unread messages. No need to check/reset
> * syslog_partial. When a reader does read a new
> * message it will notice and appropriately update
> * syslog_seq and reset syslog_partial.
> */
> logbuf_unlock_irq();
> return 0;
> }
> if (info.seq != syslog_seq) {
> /* messages are gone, move to first one */
> syslog_seq = info.seq;
> syslog_partial = 0;
> }
John Ogness
next prev parent reply other threads:[~2021-02-10 18:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 14:17 [PATCH] printk: avoid prb_first_valid_seq() where possible John Ogness
2021-02-08 6:44 ` Sergey Senozhatsky
2021-02-08 9:21 ` John Ogness
2021-02-09 0:15 ` J. Avila
2021-02-10 18:00 ` John Ogness
2021-02-09 2:17 ` Sergey Senozhatsky
2021-02-09 17:47 ` Petr Mladek
2021-02-10 18:26 ` John Ogness [this message]
2021-02-11 11:05 ` 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=874kij4w59.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=elavila@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.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