Re: [PATCH printk v3 6/6] printk: syslog: close window between wait and read

From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk v3 6/6] printk: syslog: close window between wait and read
Date: Thu, 24 Jun 2021 17:25:27 +0200	[thread overview]
Message-ID: <YNSj59rKfGARoWRD@alley> (raw)
In-Reply-To: <20210624111148.5190-7-john.ogness@linutronix.de>

On Thu 2021-06-24 13:17:48, John Ogness wrote:
> Syslog's SYSLOG_ACTION_READ is supposed to block until the next
> syslog record can be read, and then it should read that record.
> However, because @syslog_lock is not held between waking up and
> reading the record, another reader could read the record first,
> thus causing SYSLOG_ACTION_READ to return with a value of 0, never
> having read _anything_.
> 
> By holding @syslog_lock between waking up and reading, it can be
> guaranteed that SYSLOG_ACTION_READ blocks until it successfully
> reads a syslog record (or a real error occurs).
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
>  kernel/printk/printk.c | 50 +++++++++++++++++++++++++++++++-----------
>  1 file changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 90954cb5a0ab..4737804d6c6d 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1542,8 +1570,13 @@ static int syslog_print(char __user *buf, int size)
>  		len += n;
>  		size -= n;
>  		buf += n;
> -	}
>  
> +		if (!size)
> +			break;

This looks like an unrelated optimization. If I get it correctly,
it does not change the existing behavior. The next cycle would
end up with n == 0 and break anyway.

It would have been better to do it in a separate patch or do not do
it at all or at least mention it in the commit message.

> +
> +		mutex_lock(&syslog_lock);
> +	}
> +out:
>  	kfree(text);
>  	return len;
>  }

The patch itself makes sense. It somehow fixes a long standing race.
Even though the result still might be racy. The lock is released
when each record is copied to the user-provided buffer.

I do not want to block it because of details. Feel free to use:

Reviewed-by: Petr Mladek <pmladek@suse.com>

but I would feel more comfortable if we handled the optimization one
of the suggested way.

Best Regards,
Petr