Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t to avoid split locks

[Sean Christopherson <seanjc@google.com>]

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.