All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Andi Kleen <ak@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Michal Hocko <mhocko@kernel.org>,
	stable@vger.kernel.org, Christopher Snowhill <kode54@gmail.com>,
	George Anchev <studio@anchev.net>
Subject: Re: [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has too much RAM
Date: Thu, 23 Aug 2018 22:20:35 +0200	[thread overview]
Message-ID: <f4996252-85ca-eccc-af62-0b8572a3ffc0@suse.cz> (raw)
In-Reply-To: <20180823154437.GC12066@tassilo.jf.intel.com>

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
> 


  reply	other threads:[~2018-08-23 20:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 13:44 [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has too much RAM Vlastimil Babka
2018-08-23 13:56 ` Michal Hocko
2018-08-23 14:28 ` [PATCH] x86/speculation/l1tf: suggest what to do on systems with " Vlastimil Babka
2018-08-23 15:46   ` Andi Kleen
2018-08-23 19:25     ` Michal Hocko
2018-08-23 19:38       ` Andi Kleen
2018-08-23 20:05         ` Michal Hocko
2018-08-23 22:07           ` Andi Kleen
2018-08-23 19:03   ` kbuild test robot
2018-08-23 19:23   ` kbuild test robot
2018-08-23 19:27   ` Michal Hocko
2018-08-24  7:32     ` Vlastimil Babka
2018-08-24  7:32       ` Vlastimil Babka
2018-08-24  7:55       ` [tip:x86/urgent] x86/speculation/l1tf: Suggest " tip-bot for Vlastimil Babka
2018-08-24 10:36       ` [PATCH] x86/speculation/l1tf: suggest " Vlastimil Babka
2018-08-24 12:10         ` Vlastimil Babka
2018-08-24 12:10           ` Vlastimil Babka
2018-08-24 12:20           ` Michal Hocko
2018-08-24 13:57       ` [tip:x86/urgent] x86/speculation/l1tf: Suggest " tip-bot for Vlastimil Babka
2018-08-23 15:44 ` [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has " Andi Kleen
2018-08-23 20:20   ` Vlastimil Babka [this message]
2018-08-24  2:22   ` Andre Tomt
2018-08-24  3:35     ` Andi Kleen
2018-08-29  2:04     ` Christopher Snowhill
2018-08-24  8:52   ` xxxxxx xxxxxx
2018-08-24  7:55 ` [tip:x86/urgent] x86/speculation/l1tf: Fix " tip-bot for Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4996252-85ca-eccc-af62-0b8572a3ffc0@suse.cz \
    --to=vbabka@suse.cz \
    --cc=ak@linux.intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=kode54@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=studio@anchev.net \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.