public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
@ 2022-08-02  3:32 Chenyi Qiang
  2022-08-02 10:51 ` Ingo Molnar
  2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang
  0 siblings, 2 replies; 5+ messages in thread
From: Chenyi Qiang @ 2022-08-02  3:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	Tony Luck, Fenghua Yu
  Cc: Chenyi Qiang, linux-kernel, x86

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 <chenyi.qiang@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 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


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
  2022-08-02  3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
@ 2022-08-02 10:51 ` Ingo Molnar
  2022-08-02 11:29   ` Chenyi Qiang
  2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang
  1 sibling, 1 reply; 5+ messages in thread
From: Ingo Molnar @ 2022-08-02 10:51 UTC (permalink / raw)
  To: Chenyi Qiang
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	Tony Luck, Fenghua Yu, linux-kernel, x86


* Chenyi Qiang <chenyi.qiang@intel.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
  2022-08-02 10:51 ` Ingo Molnar
@ 2022-08-02 11:29   ` Chenyi Qiang
  2022-08-02 11:42     ` Ingo Molnar
  0 siblings, 1 reply; 5+ messages in thread
From: Chenyi Qiang @ 2022-08-02 11:29 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	Tony Luck, Fenghua Yu, linux-kernel, x86



On 8/2/2022 6:51 PM, Ingo Molnar wrote:
> 
> * Chenyi Qiang <chenyi.qiang@intel.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
  2022-08-02 11:29   ` Chenyi Qiang
@ 2022-08-02 11:42     ` Ingo Molnar
  0 siblings, 0 replies; 5+ messages in thread
From: Ingo Molnar @ 2022-08-02 11:42 UTC (permalink / raw)
  To: Chenyi Qiang
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	Tony Luck, Fenghua Yu, linux-kernel, x86


* Chenyi Qiang <chenyi.qiang@intel.com> wrote:

> 
> 
> On 8/2/2022 6:51 PM, Ingo Molnar wrote:
> > 
> > * Chenyi Qiang <chenyi.qiang@intel.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [tip: x86/urgent] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
  2022-08-02  3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
  2022-08-02 10:51 ` Ingo Molnar
@ 2022-08-02 11:57 ` tip-bot2 for Chenyi Qiang
  1 sibling, 0 replies; 5+ messages in thread
From: tip-bot2 for Chenyi Qiang @ 2022-08-02 11:57 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: Chenyi Qiang, Ingo Molnar, Tony Luck, x86, linux-kernel

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 <chenyi.qiang@intel.com>
AuthorDate:    Tue, 02 Aug 2022 11:32:06 +08:00
Committer:     Ingo Molnar <mingo@kernel.org>
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 <chenyi.qiang@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20220802033206.21333-1-chenyi.qiang@intel.com
---
 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);
 }
 

^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-08-02 11:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-02  3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
2022-08-02 10:51 ` Ingo Molnar
2022-08-02 11:29   ` Chenyi Qiang
2022-08-02 11:42     ` Ingo Molnar
2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox