Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 23 Sep 2020 16:52:08 +0200
From:   Petr Mladek <pmladek@suse.com>
To:     John Ogness <john.ogness@linutronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk 2/5] printk: kmsg_dump_rewind_nolock: start from
 first record
Message-ID: <20200923145208.GB6442@alley>
References: <20200922153816.5883-1-john.ogness@linutronix.de>
 <20200922153816.5883-3-john.ogness@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200922153816.5883-3-john.ogness@linutronix.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue 2020-09-22 17:44:13, John Ogness wrote:
> kmsg_dump_rewind_nolock() accesses @clear_seq without any locking.
> However, accessing this global variable requires holding
> @logbuf_lock. For the _nolock() variant, start from the first record
> in the ringbuffer rather than the @clear_seq record.

> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
>  kernel/printk/printk.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 00bc1fce3299..cff13b33e926 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3410,11 +3410,12 @@ EXPORT_SYMBOL_GPL(kmsg_dump_get_buffer);
>   * kmsg_dump_get_buffer() can be called again and used multiple
>   * times within the same dumper.dump() callback.
>   *
> - * The function is similar to kmsg_dump_rewind(), but grabs no locks.
> + * The function is similar to kmsg_dump_rewind(), but grabs no locks
> + * and starts from the oldest record rather than from @clear_seq.
>   */
>  void kmsg_dump_rewind_nolock(struct kmsg_dumper *dumper)
>  {
> -	dumper->cur_seq = clear_seq;
> +	dumper->cur_seq = 0;

Just to understand it. Is the problem that the value might be in
an inconsistent state?

I mean that it might be modified by more instructions, for example,
because of compiler optimizations or on 32-bit system by definition.

I still have to look at the later patches. But it seems that
the new syslog_lock is taken mostly only around reading or
writing the global @clear_seq variable. Atomic variable might
do the same job.

Best Regards,
Petr