On 2021-03-01, Petr Mladek <pmla...@suse.com> wrote: >> The kmsg_dumper can be called from any context and CPU, possibly >> from multiple CPUs simultaneously. Since the writing of the buffer >> can occur from a later scheduled work queue, the oops buffer must >> be protected against simultaneous dumping. >> >> Use an atomic bit to mark when the buffer is protected. Release the >> protection in between setting the buffer and the actual writing in >> order for a possible panic (immediate write) to be written during >> the scheduling of a previous oops (delayed write). > > Just to be sure. You did not use spin lock to prevent problems > with eventual double unlock in panic(). Do I get it correctly, > please?
I do not understand what possible double unlock you are referring to. I chose not to use spinlocks because I wanted something that does not cause any scheduling or preemption side-effects for mtd. The mtd dumper sometimes dumps directly, sometimes delayed (via scheduled work), and they use different mtd callbacks in different contexts. mtd_write() expects to be called in a non-atomic context. The callbacks can take a mutex. John Ogness