Messages in this thread |  | | Date | Thu, 4 Apr 2024 08:26:29 -0700 | | Subject | Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t to avoid split locks | | From | Sean Christopherson <> |
| |
On Wed, Apr 03, 2024, Dave Hansen wrote: > On 4/3/24 08:54, Javier Pello wrote: > > - The third way would be to disable split lock detection on x86-32. > > This can be as simple as setting the default to "none" in > > sld_state_setup(). Not the most elegant of solutions, but beats > > having unresponsive tasks. > > > > Would going for the first one be worth the trouble? > > No, it's not worth it. Let's just disable split lock detection on > 32-bit and move on with life.
Please don't paper over the kernel flaw by disabling split lock detection. As Brian alluded to with his question:
: What would happen if you ran a 32-bit VM on such hardware? If the : split lock detection on the guest were disabled, would the host get : the fault instead?
running these kernels under a hypervisor that has enabled split-lock detection, or Intel's newfangled BUS_LOCK_DETECTION VM-Exit, will result in silently degraded performance for the guest kernel. The split-lock will trap to the hypervisor, which will likely throttle the vCPU to guard against a DoS attack, e.g. under KVM, IIRC the default behavior for split-lock is to stall the task for 10 _milliseconds_.
In other words, practically speaking this isn't about supporting a new hardware feature on 32-bit kernels, it's about preserving performance in real world scenarios when running 32-bit kernels on new hardware. And that means keeping split-lock detection enabled on 32-bit kernels is a good thing, as kernels bugs that would cause hard-to-debug _customer_ issues when running 32-bit Linux in a VM will show up as easy-to-debug splats when running 32-bit kernels on bare metal. I doubt there are many people that are still running 32-bit kernels on bare metal, but any coverage we can get would be very nice to have.
|  |