On 2021-02-01, Petr Mladek <[email protected]> wrote: >> Rather than store the iterator information into the registered >> kmsg_dump structure, create a separate iterator structure. The >> kmsg_dump_iter structure can reside on the stack of the caller, >> thus allowing lockless use of the kmsg_dump functions. >> >> This is in preparation for removal of @logbuf_lock. > >> diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h >> index 76cc4122d08e..ecc98f549d93 100644 >> --- a/include/linux/kmsg_dump.h >> +++ b/include/linux/kmsg_dump.h >> @@ -29,6 +29,18 @@ enum kmsg_dump_reason { >> KMSG_DUMP_MAX >> }; >> >> +/** >> + * struct kmsg_dumper_iter - iterator for kernel crash message dumper >> + * @active: Flag that specifies if this is currently dumping >> + * @cur_seq: The record to dump (private) >> + * @next_seq: The first record of the next block (private) > > Just to be sure. This description should get update if you agree with > the alternative one in the 1st patch.
Yes, I assumed so and adjusted my preparation-v2 series accordingly. John
