: Respin local_irq_*_nmi() stuff.
in [Kernel]
|
Prev: [RFC][BUGFIX][PATCH] memcg: fix underflow of mapped_file stat
Next: blkio: Changes to IO controller additional stats patches
From: David Miller on 13 Apr 2010 01:10 I'm rescinding these patches for now, for two reasons: 1) The NMI annotations necessary to get everything working really gets out of control. 2) I think I found a cheap way to do this in sparc64 specific code. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 13 Apr 2010 03:50 On Mon, 2010-04-12 at 22:08 -0700, David Miller wrote: > I'm rescinding these patches for now, for two reasons: > > 1) The NMI annotations necessary to get everything working really gets > out of control. > > 2) I think I found a cheap way to do this in sparc64 specific code. Ah, ok.. Care to enlighten the curious amongst us as to what exactly you're doing in the sparc code? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 13 Apr 2010 04:00 From: Peter Zijlstra <peterz(a)infradead.org> Date: Tue, 13 Apr 2010 09:48:58 +0200 > Care to enlighten the curious amongst us as to what exactly you're > doing in the sparc code? From 0c25e9e6cbe7b233bb91d14d0e2c258bf8e6ec83 Mon Sep 17 00:00:00 2001 From: David S. Miller <davem(a)davemloft.net> Date: Mon, 12 Apr 2010 22:21:52 -0700 Subject: [PATCH 2/2] sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs. If we are in an NMI then doing a plain raw_local_irq_disable() will write PIL_NORMAL_MAX into %pil, which is lower than PIL_NMI, and thus we'll re-enable NMIs and recurse. Doing a simple: %pil = %pil | PIL_NORMAL_MAX does what we want, if we're already at PIL_NMI (15) we leave it at that setting, else we set it to PIL_NORMAL_MAX (14). This should get the function tracer working on sparc64. Signed-off-by: David S. Miller <davem(a)davemloft.net> --- arch/sparc/include/asm/irqflags_64.h | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/sparc/include/asm/irqflags_64.h b/arch/sparc/include/asm/irqflags_64.h index 8b49bf9..a16e94c 100644 --- a/arch/sparc/include/asm/irqflags_64.h +++ b/arch/sparc/include/asm/irqflags_64.h @@ -76,9 +76,19 @@ static inline int raw_irqs_disabled(void) */ static inline unsigned long __raw_local_irq_save(void) { - unsigned long flags = __raw_local_save_flags(); + unsigned long flags, tmp; - raw_local_irq_disable(); + /* Disable interrupts to PIL_NORMAL_MAX unless we already + * are using PIL_NMI, in which case PIL_NMI is retained. + */ + __asm__ __volatile__( + "rdpr %%pil, %0\n\t" + "or %0, %2, %1\n\t" + "wrpr %1, 0x0, %%pil" + : "=r" (flags), "=r" (tmp) + : "i" (PIL_NORMAL_MAX) + : "memory" + ); return flags; } -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 13 Apr 2010 04:40 On Tue, 2010-04-13 at 00:56 -0700, David Miller wrote: > If we are in an NMI then doing a plain raw_local_irq_disable() will > write PIL_NORMAL_MAX into %pil, which is lower than PIL_NMI, and thus > we'll re-enable NMIs and recurse. > > Doing a simple: > > %pil = %pil | PIL_NORMAL_MAX > > does what we want, if we're already at PIL_NMI (15) we leave it at > that setting, else we set it to PIL_NORMAL_MAX (14). Ah indeed, and without a conditional, very nice! It does rely on the exact values of the PIL_levels, it might make sense to note that in the comment, something like: * Assumes: PIL_NMI | PIL_NORMAL_MAX == PIL_NMI. Hmm, it also assumes %pil is never anything other than 0, PIL_NORMAL_MAX, PIL_NMI, because if: (%pil & 1) && (%pil != PIL_NMI) then you'll end up disabling NMIs. Could something like that ever happen? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 13 Apr 2010 04:50
From: Peter Zijlstra <peterz(a)infradead.org> Date: Tue, 13 Apr 2010 10:37:14 +0200 > Hmm, it also assumes %pil is never anything other than 0, > PIL_NORMAL_MAX, PIL_NMI, because if: > > (%pil & 1) && (%pil != PIL_NMI) > > then you'll end up disabling NMIs. Could something like that ever > happen? The only values we ever program into the %pil are 0, PIL_NORMAL_MAX and PIL_NMI Since PIL_NMI is the largest %pil value and all bits are set in it (0xf), it doesn't matter what PIL_NORMAL_MAX actually is. Yes this all deserves a comment, I'll add one, thanks for pointing that out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |