linux-kernel - Re: [PATCH printk 2/5] printk: kmsg_dump_rewind

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87lfh0zems.fsf@jogness.linutronix.de>
Date:   Wed, 23 Sep 2020 17:45:23 +0206
From:   John Ogness <john.ogness@...utronix.de>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk 2/5] printk: kmsg_dump_rewind_nolock: start from first record

On 2020-09-23, Petr Mladek <pmladek@...e.com> 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@...utronix.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.

Correct.

> 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.

Until now I have avoided using atomic64 types. Perhaps my reluctance to
use this type is unfounded. Using an atomic64 for @clear_seq would free
it from needing to be protected by @syslog_lock.

John Ogness