On Fri, Jan 31, 2020 at 01:57:31PM +0100, Pavel Machek wrote:
On Thu 2020-01-30 19:39:17, Greg Kroah-Hartman wrote:
From: Fenghua Yu fenghua.yu@intel.com
[ Upstream commit f11421ba4af706cb4f5703de34fa77fba8472776 ]
This is not suitable for stable. It does not fix anything.
It fixes the code for BE at the very least.
It prepares for theoretical bug that author claims might be introduced to BIOS in future... I doubt it, even BIOS authors boot their machines from time to time.
BIOS authors might not enable this (optional) feature.
Atomic operations that span cache lines are super-expensive on x86 (not just to the current processor, but also to other processes as all memory operations are blocked until the operation completes). Upcoming x86 processors have a switch to cause such operations to generate a #AC trap. It is expected that some real time systems will enable this mode in BIOS.
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?
Or you could, you know, like google it. Try "intel split lock detection". It is a feature the OS can enable which will result in #AC exceptions when memops to LOCK prefixed instructions are not properly aligned (because their performance sucks and it impacts execution across the machine, not just the local CPU).
In preparation for this, it is necessary to fix code that may execute atomic instructions with operands that cross cachelines because the #AC trap will crash the kernel.
How does single bit operation "cross cacheline"? How is this going to impact non-x86 architectures?
The actual instruction is "LOCK BTSQ", which is a 64bit wide instruction (LOCK BTSL on 32bit kernels). The memory operand of that instruction is (stupidly IMO) allowed to be non aligned.
Any sane architecture (ie, pretty much everyone else) will already trap when you try unaligned atomic ops (or even unaligned anything for most RISCs).
Since "pwol_mask" is local and never exposed to concurrency, there is no need to set bits in pwol_mask using atomic operations.
Directly operate on the byte which contains the bit instead of using __set_bit() to avoid any big endian concern due to type cast to unsigned long in __set_bit().
What concerns? Is __set_bit() now useless and are we going to open-code it everywhere? Is set_bit() now unusable on x86?
As David already explained, the bitops are defined on long[], are employed on u8[] here (clue the (unsigned long *) cast) and would do completely the wrong thing on BE.
set_bit() works as advertised when used as specified; on long[].