On Fri, Jan 31, 2020 at 01:57:31PM +0100, Pavel Machek wrote:
And I wonder if this is even good idea for mainline. x86 architecture is here for long time, and I doubt Intel is going to break it like this. Do you have documentation pointer?
Intel isn't breaking this legacy behaviour. But it is building h/w that allows s/w to opt-in to a mode that will generate an #AC trap for a split lock. One such processor ("Icelake") is already shipping.
Some Linux use cases (real-time) really, really want to avoid the cost of a split-lock. There's a patch in TIP that will enable this #AC on split-lock mode on processors that support it.
Thus it's a good idea to clean up any places in the kernel that will cause #AC when that mode is enabled. I think mainline should be taking any patches for split lock cleanup.
Stable is a different question. The patch to enable the #AC should not be backported to stable. So the only way an old kernel would hit this would be if the BIOS enabled the #AC. Really that should only happen on a system where the developers have validated that the entire software stack has been checked for split locks.
Is net/b44 a device that is still being included on current systems? Or is it a legacy device that has been superceeded by something else? If there isn't going to be a b44 on an Icelake or newer system, then perhaps we should not worry so much about fixing the driver.
-Tony