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 <[email protected]> > --- > 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
