> Instead of introducing the panic lock, as an alternative we could move > smp_send_stop() to the beginning of panic(). Eric told me that the > function is currently "insufficiently reliable" for that, but perhaps we > could make it more reliable. That's tough to do. We are in panic because something went horribly wrong somewhere in the kernel - so we can make few assumptions about which subsystems are still working. In the worst case (for this example) our panic was caused by a failure in the code that sends cross-processor interrupts ... so calling that same code to stop the other cpus is likely to run into the same problem - perhaps causing a nested panic. So what looks like a good fix for some panic scenarios actually makes others worse. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
