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

  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