It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
this kernel has been kexec'd from a kernel that enabled bus lock
detection.
Disable bus lock detection explicitly if not wanted.
Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock")
Signed-off-by: Chenyi Qiang <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
---
arch/x86/kernel/cpu/intel.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fd5dead8371c..cb796ca6eff5 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1216,22 +1216,23 @@ static void bus_lock_init(void)
{
u64 val;
- /*
- * Warn and fatal are handled by #AC for split lock if #AC for
- * split lock is supported.
- */
- if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT) ||
- (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
- (sld_state == sld_warn || sld_state == sld_fatal)) ||
- sld_state == sld_off)
+ if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
return;
- /*
- * Enable #DB for bus lock. All bus locks are handled in #DB except
- * split locks are handled in #AC in the fatal case.
- */
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
- val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+
+ if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
+ (sld_state == sld_warn || sld_state == sld_fatal)) ||
+ sld_state == sld_off) {
+ /*
+ * Warn and fatal are handled by #AC for split lock if #AC for
+ * split lock is supported.
+ */
+ val &= ~DEBUGCTLMSR_BUS_LOCK_DETECT;
+ } else {
+ val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+ }
+
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
}
--
2.17.1
* Chenyi Qiang <[email protected]> wrote:
> It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
> this kernel has been kexec'd from a kernel that enabled bus lock
> detection.
>
> Disable bus lock detection explicitly if not wanted.
Makes sense.
Just curious: in what circumstances does the BIOS/firmware set
DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
spurious reason, without really using the feature? (Assuming you are aware
of instances where this happened - or was this simply a hypothetical?)
Thanks,
Ingo
On 8/2/2022 6:51 PM, Ingo Molnar wrote:
>
> * Chenyi Qiang <[email protected]> wrote:
>
>> It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
>> this kernel has been kexec'd from a kernel that enabled bus lock
>> detection.
>>
>> Disable bus lock detection explicitly if not wanted.
>
> Makes sense.
>
> Just curious: in what circumstances does the BIOS/firmware set
> DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
> spurious reason, without really using the feature? (Assuming you are aware
> of instances where this happened - or was this simply a hypothetical?)
Yes, It's just a hypothetical for BIOS/firmware. Kexec is the real case
I met with this problem.
>
> Thanks,
>
> Ingo
* Chenyi Qiang <[email protected]> wrote:
>
>
> On 8/2/2022 6:51 PM, Ingo Molnar wrote:
> >
> > * Chenyi Qiang <[email protected]> wrote:
> >
> > > It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
> > > this kernel has been kexec'd from a kernel that enabled bus lock
> > > detection.
> > >
> > > Disable bus lock detection explicitly if not wanted.
> >
> > Makes sense.
> >
> > Just curious: in what circumstances does the BIOS/firmware set
> > DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
> > spurious reason, without really using the feature? (Assuming you are aware
> > of instances where this happened - or was this simply a hypothetical?)
>
> Yes, It's just a hypothetical for BIOS/firmware. Kexec is the real case I
> met with this problem.
Fair enough, I've tweaked the changelog a bit to de-emphasize the firmware
angle, and applied your fix to tip:x86/urgent.
Thanks,
Ingo
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ffa6482e461ff550325356ae705b79e256702ea9
Gitweb: https://git.kernel.org/tip/ffa6482e461ff550325356ae705b79e256702ea9
Author: Chenyi Qiang <[email protected]>
AuthorDate: Tue, 02 Aug 2022 11:32:06 +08:00
Committer: Ingo Molnar <[email protected]>
CommitterDate: Tue, 02 Aug 2022 13:42:00 +02:00
x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
It's possible that this kernel has been kexec'd from a kernel that
enabled bus lock detection, or (hypothetically) BIOS/firmware has set
DEBUGCTLMSR_BUS_LOCK_DETECT.
Disable bus lock detection explicitly if not wanted.
Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock")
Signed-off-by: Chenyi Qiang <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
arch/x86/kernel/cpu/intel.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 663f6e6..2d7ea54 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1216,22 +1216,23 @@ static void bus_lock_init(void)
{
u64 val;
- /*
- * Warn and fatal are handled by #AC for split lock if #AC for
- * split lock is supported.
- */
- if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT) ||
- (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
- (sld_state == sld_warn || sld_state == sld_fatal)) ||
- sld_state == sld_off)
+ if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
return;
- /*
- * Enable #DB for bus lock. All bus locks are handled in #DB except
- * split locks are handled in #AC in the fatal case.
- */
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
- val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+
+ if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
+ (sld_state == sld_warn || sld_state == sld_fatal)) ||
+ sld_state == sld_off) {
+ /*
+ * Warn and fatal are handled by #AC for split lock if #AC for
+ * split lock is supported.
+ */
+ val &= ~DEBUGCTLMSR_BUS_LOCK_DETECT;
+ } else {
+ val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+ }
+
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
}