On 17/06/22 15:52, Petr Mladek wrote: > On Fri 2022-06-17 12:52:05, Valentin Schneider wrote: >> If you look at __crash_kexec() in isolation yes, but if you look at panic() >> and nmi_panic() only a single NMI can get in there. I think that is also >> true for invocations via crash_kexec(). > > It is true that panic() could be called only once, see this code > in panic(): > > * Only one CPU is allowed to execute the panic code from here. For > this_cpu = raw_smp_processor_id(); > old_cpu = atomic_cmpxchg(&panic_cpu, PANIC_CPU_INVALID, this_cpu); > > if (old_cpu != PANIC_CPU_INVALID && old_cpu != this_cpu) > panic_smp_self_stop(); > > > One the other hand, the aproach with two variables is strage > and brings exactly these questions. > > If a trylock is enough that the mutex can be replaced by two > simple atomic operations. The mutex would be needed only > when a user really would need to wait for another one. > > > atomic_t crash_kexec_lock; > > /* trylock part */ > if (atomic_cmpxchg_acquire(&crash_kexec_lock, 0, 1) != 0) > return -EBUSY; > > /* do anything guarded by crash_kexec_lock */ > > /* release lock */ > atomic_set_release(&crash_kexec_lock, 0); > > The _acquire, _release variants will do the barriers correctly. >
Looks saner! I can't think of anything wrong with it so I'll shove that in v2. Thanks! > Best Regards, > Petr _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
