lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251031053832.99453-1-fushuai.wang@linux.dev>
Date: Fri, 31 Oct 2025 13:38:32 +0800
From: Fushuai Wang <fushuai.wang@...ux.dev>
To: bp@...en8.de
Cc: dave.hansen@...ux.intel.com,
	davydov-max@...dex-team.ru,
	gpiccoli@...lia.com,
	hpa@...or.com,
	jani.nikula@...el.com,
	joel.granados@...nel.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	martin.petersen@...cle.com,
	mingo@...hat.com,
	peterz@...radead.org,
	tglx@...utronix.de,
	wangfushuai@...du.com,
	x86@...nel.org,
	xin@...or.com
Subject: Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

>> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ