On 8/23/18 5:44 PM, Andi Kleen wrote:
On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
Two users have reported [1] that they have an "extremely unlikely" system with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes in the e820 map, the main region is almost 500MB over the 32GB limit:
Ah I see it's a client part with very large DIMMs and someone being very brave and using that much memory without ECC.
Are you trying to mock the users and diminsh their report because of that?
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000081effffff] usable
Suggestions to use 'mem=32G' to prefer L1TF mitigation while losing the 500MB revealed, that there's an off-by-one error in the check in l1tf_select_mitigation(). l1tf_pfn_limit() returns the last usable pfn (inclusive), but it's more common and hopefully less error-prone to return the first pfn that's over limit, so this patch changes that and updates the other callers.
I can see the off by one, but does it really cause the user's problem?
They will be still over the limit in any case, with or without off-by-one.
So the description has nothing to do with the fix. Or do I miss something?
The off-by-one happens when 'mem=32G' is used to limit the amount memory. It's easier to do "mem=32G" with fixed code than "mem=33554428k" to workaround the error.
-Andi