On Thu, Jul 16, 2015 at 10:13:26AM +0100, Daniel Thompson wrote: > On 15/07/15 21:39, Russell King wrote: > >As we now have generic infrastructure to support backtracing of other > >CPUs in the system on lockups, we can start to implement this for ARM. > >Initially, we add an IPI based implementation, as the GIC code needs > >modification to support the generation of FIQ IPIs, and not all ARM > >platforms have the ability to raise a FIQ in the non-secure world. > > > >This provides us with a "best efforts" implementation in the absence > >of FIQs. > > > >Signed-off-by: Russell King <[email protected]> > >--- > >diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c > >index 90dfbedfbfb8..3a20c386fd33 100644 > >--- a/arch/arm/kernel/smp.c > >+++ b/arch/arm/kernel/smp.c > >@@ -21,6 +21,7 @@ > > #include <linux/cpu.h> > > #include <linux/seq_file.h> > > #include <linux/irq.h> > >+#include <linux/nmi.h> > > #include <linux/percpu.h> > > #include <linux/clockchips.h> > > #include <linux/completion.h> > >@@ -72,6 +73,7 @@ enum ipi_msg_type { > > IPI_CPU_STOP, > > IPI_IRQ_WORK, > > IPI_COMPLETION, > >+ IPI_CPU_BACKTRACE = 15, > > Even with the potential for (eventually) being signalled by FIQ, is this IPI > really so special it needs to be placed outside the scope of NR_IPI and the > accounting and tracing support it brings with it?
That's exactly why it's placed outside that range. We don't want the accounting and tracing stuff at all in that path - that's more code which needs to be run which could be the cause of the lockup. More fragility. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
