Jan Kara <j...@suse.cz> writes: >> --- >> a/kernel/panic.c~panic-release-stale-console-lock-to-always-get-the-logbuf-printed-out-fix >> +++ a/kernel/panic.c >> @@ -149,10 +149,10 @@ void panic(const char *fmt, ...) >> bust_spinlocks(0); >> >> /* >> - * We may have ended up killing the CPU holding the lock and still have >> - * some valuable data in console buffer. Try to acquire the lock and >> - * release it regardless of the result. The release will also print the >> - * buffers out. >> + * We may have ended up stopping the CPU holding the lock (in >> + * smp_send_stop()) while still having some valuable data in the console >> + * buffer. Try to acquire the lock then release it regardless of the >> + * result. The release will also print the buffers out. >> */ >> console_trylock(); >> console_unlock(); >> _ >> >> >> Does the console_trylock() guarantee that the console lock is now held? >> If the console_lock-holding CPU is still running then there's a window >> where the above code could enter console_unlock() when nobody's holding >> console_lock. If smp_send_stop() always works (synchronously) then >> that won't happen. > > We have this mechanism using zap_locks() in kernel/printk/printk.c when > crash happens on the CPU holding console_sem. Can't we use the same > mechanism for this case? Something like adding: > > zap_locks(); > console_lock(); > console_unlock(); > > to panic?
I thought it doesn't really matter who holds the lock at this point -- all other cpus were already stopped with IPIs/NMIs. > If we picked up patch "kernel: Avoid softlockups in > stop_machine() during heavy printing" from my series (it's completely > independent, I've attached the latest version), the result would look less > hacky to me (attached). Thoughts? Haven't tested it but should also work... Thanks, -- Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
