Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH printk 2/5] printk: kmsg_dump_rewind_nolock: start from first record | Date | Wed, 23 Sep 2020 17:45:23 +0206 |
| |
On 2020-09-23, Petr Mladek <pmladek@suse.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@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.
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
| |