[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220511131733.4074499-1-mark.rutland@arm.com>
Date: Wed, 11 May 2022 14:17:31 +0100
From: Mark Rutland <mark.rutland@....com>
To: linux-arm-kernel@...ts.infradead.org
Cc: catalin.marinas@....com, linux-kernel@...r.kernel.org,
mark.rutland@....com, mingo@...nel.org, peterz@...radead.org,
tglx@...utronix.de, will@...nel.org
Subject: [PATCH 0/2] arm64: fix lockdep in NMI context
For lockdep to function correctly in NMI context, architectures need to
correctly save/restore lockdep state at NMI entry/exit time, correctly
manage lockdep state within the NMI context, and need to select
TRACE_IRQFLAGS_NMI_SUPPORT.
Currently arm64 falls short of this merely by failing to select
TRACE_IRQFLAGS_NMI_SUPPORT, and this can result in spurious lockdep
splats with GICv3 Pseudo-NMIs are in use. Patch 2 has an example.
Patch 1 makes TRACE_IRQFLAGS_NMI_SUPPORT a generically selectable
kconfig symbol (as it is currently defined under arch/x86). Patch 2
selects this on arm64 (providing the behaviour we'd intended when
reworking our entry code).
For anyone testing, beware that there are some other latent issues with
GICv3 Pseudo-NMIs. I'm currently working to fix those whcih I am aware
of, but as this is orthogonal I'd like to get it out the way on its own.
Thanks,
Mark.
Mark Rutland (2):
arch: make TRACE_IRQFLAGS_NMI_SUPPORT generic
arm64: select TRACE_IRQFLAGS_NMI_SUPPORT
arch/Kconfig | 3 +++
arch/arm64/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/x86/Kconfig.debug | 3 ---
4 files changed, 5 insertions(+), 3 deletions(-)
--
2.30.2
Powered by blists - more mailing lists