[PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[Fushuai Wang]

Commit 727209376f49 ("x86/split_lock: Add sysctl to control the misery
mode") introduce a sysctl 'sysctl_sld_mitigate' to control the misery
mode for split lock detection (0 to disable, 1 to enable). However,
when enabled, the sleep duration for split lockers was fixed at 10 ms.

This patch extands 'sysctl_sld_mitigate' to allow configuring the sleep
duration in milliseconds. Now, when 'sysctl_sld_mitigate' is set to
N (N > 0), split lockers will sleep for N milliseconds.

Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
---
The last email wasn't delivered. So resend it.

 Documentation/admin-guide/sysctl/kernel.rst | 4 ++--
 arch/x86/kernel/cpu/bus_lock.c              | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index f3ee807b5d8b..92e34041ea73 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1472,8 +1472,8 @@ increase system exposure to denial of service attacks from split lock users.
 = ===================================================================
 0 Disable the mitigation mode - just warns the split lock on kernel log
   and exposes the system to denials of service from the split lockers.
-1 Enable the mitigation mode (this is the default) - penalizes the split
-  lockers with intentional performance degradation.
+N Enable the mitigation mode (default is 10) - penalizes the split lockers
+  by suspending their execution for N milliseconds.
 = ===================================================================
 
 
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 981f8b1f0792..a5f0ad1b5c24 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -46,7 +46,7 @@ static const struct {
 
 static struct ratelimit_state bld_ratelimit;
 
-static unsigned int sysctl_sld_mitigate = 1;
+static unsigned int sysctl_sld_mitigate = 10;
 static DEFINE_SEMAPHORE(buslock_sem, 1);
 
 #ifdef CONFIG_PROC_SYSCTL
@@ -58,7 +58,7 @@ static const struct ctl_table sld_sysctls[] = {
 		.mode           = 0644,
 		.proc_handler	= proc_douintvec_minmax,
 		.extra1         = SYSCTL_ZERO,
-		.extra2         = SYSCTL_ONE,
+		.extra2         = SYSCTL_INT_MAX,
 	},
 };
 
@@ -252,9 +252,9 @@ static void split_lock_warn(unsigned long ip)
 	if (saved_sld_mitigate) {
 		/*
 		 * misery factor #1:
-		 * sleep 10ms before trying to execute split lock.
+		 * sleep 'saved_sld_mitigate' ms before trying to execute split lock.
 		 */
-		if (msleep_interruptible(10) > 0)
+		if (msleep_interruptible(saved_sld_mitigate) > 0)
 			return;
 		/*
 		 * Misery factor #2:
-- 
2.36.1

Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[Borislav Petkov]

On Tue, Oct 28, 2025 at 05:43:33PM +0800, Fushuai Wang wrote:
> Commit 727209376f49 ("x86/split_lock: Add sysctl to control the misery
> mode") introduce a sysctl 'sysctl_sld_mitigate' to control the misery
> mode for split lock detection (0 to disable, 1 to enable). However,
> when enabled, the sleep duration for split lockers was fixed at 10 ms.
> 
> This patch extands 'sysctl_sld_mitigate' to allow configuring the sleep
> duration in milliseconds. Now, when 'sysctl_sld_mitigate' is set to
> N (N > 0), split lockers will sleep for N milliseconds.

I'm reading this and the only question that pops up in my mind is "why".

Why does the upstream kernel need this?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[Fushuai Wang]

>> Commit 727209376f49 ("x86/split_lock: Add sysctl to control the misery
>> mode") introduce a sysctl 'sysctl_sld_mitigate' to control the misery
>> mode for split lock detection (0 to disable, 1 to enable). However,
>> when enabled, the sleep duration for split lockers was fixed at 10 ms.
>> 
>> This patch extands 'sysctl_sld_mitigate' to allow configuring the sleep
>> duration in milliseconds. Now, when 'sysctl_sld_mitigate' is set to
>> N (N > 0), split lockers will sleep for N milliseconds.
>
> I'm reading this and the only question that pops up in my mind is "why".
> 
> Why does the upstream kernel need this?
-------
Resend. It was not delivered successfully again. :(
-------

Hi Boris,

I think there are two main reasons for making the split lock mitigation
sleep duration configurable:

1.Workload Flexibility: Different workloads have varying sensitivity to
  latency. Some environments may want a longer penalty to strongly discourage
  split locks, while others may prefer a shorter delay to minimize impact on
  overall system responsiveness.For example, in cloud environments, we are
  often more sensitive to split locks because it is important to prevent a
  single virtual machine from impacting the performance of the entire physical
  host, so a stricter (longer) penalty may be preferred. In other scenarios,
  such a strict penalty may not be necessary, and a shorter delay might be
  sufficient to balance performance and stability. Making the sleep duration
  configurable allows administrators to adjust the mitigation strategy based
  on the specific requirements and tolerance levels of different environments.

2.Testing and Tuning: Allowing the sleep duration to be configured makes
  it easier for system administrators and developers to test the effects of
  different mitigation levels and to tune the system according to their
  specific requirements.

Regards,
Wang.

Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[Borislav Petkov]

On Fri, Oct 31, 2025 at 10:46:31AM +0800, Fushuai Wang wrote:
> I think there are two main reasons for making the split lock mitigation
> sleep duration configurable:

IOW, you want to disable split lock.

What's the point otherwise?

Apparently you want to do some sort of a solution for a cloud environment but
you can't make everyone happy.

So you either allow split locks or you slow down offenders. Making this
configurable doesn't make a whole lotta sense to me unless you write a proper,
concrete use case which justifies this and not some AI-generated bla.

If not, you can just as well keep this in your kernels and use it there.

I do not see the point of adding this in the upstream kernel.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette