All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
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>,
	Andi Kleen <ak@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	stable@vger.kernel.org, Christopher Snowhill <kode54@gmail.com>,
	xxxxxx xxxxxx <xxxxxx@xxxxxx.xxx>
Subject: Re: [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has too much RAM
Date: Thu, 23 Aug 2018 15:56:33 +0200	[thread overview]
Message-ID: <20180823135633.GN29735@dhcp22.suse.cz> (raw)
In-Reply-To: <20180823134418.17008-1-vbabka@suse.cz>

On Thu 23-08-18 15:44:18, 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:
> 
> [    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.
> 
> [1] https://bugzilla.suse.com/show_bug.cgi?id=1105536
> 
> Reported-by: xxxxxx xxxxxx <xxxxxx@xxxxxx.xxx>
> Reported-by: Christopher Snowhill <kode54@gmail.com>
> Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Yes this should be less error prone.
Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  arch/x86/include/asm/processor.h | 2 +-
>  arch/x86/mm/init.c               | 2 +-
>  arch/x86/mm/mmap.c               | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index a0a52274cb4a..c24297268ebc 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -183,7 +183,7 @@ extern void cpu_detect(struct cpuinfo_x86 *c);
>  
>  static inline unsigned long long l1tf_pfn_limit(void)
>  {
> -	return BIT_ULL(boot_cpu_data.x86_phys_bits - 1 - PAGE_SHIFT) - 1;
> +	return BIT_ULL(boot_cpu_data.x86_phys_bits - 1 - PAGE_SHIFT);
>  }
>  
>  extern void early_cpu_init(void);
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 02de3d6065c4..63a6f9fcaf20 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -923,7 +923,7 @@ unsigned long max_swapfile_size(void)
>  
>  	if (boot_cpu_has_bug(X86_BUG_L1TF)) {
>  		/* Limit the swap file size to MAX_PA/2 for L1TF workaround */
> -		unsigned long long l1tf_limit = l1tf_pfn_limit() + 1;
> +		unsigned long long l1tf_limit = l1tf_pfn_limit();
>  		/*
>  		 * We encode swap offsets also with 3 bits below those for pfn
>  		 * which makes the usable limit higher.
> diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
> index f40ab8185d94..1e95d57760cf 100644
> --- a/arch/x86/mm/mmap.c
> +++ b/arch/x86/mm/mmap.c
> @@ -257,7 +257,7 @@ bool pfn_modify_allowed(unsigned long pfn, pgprot_t prot)
>  	/* If it's real memory always allow */
>  	if (pfn_valid(pfn))
>  		return true;
> -	if (pfn > l1tf_pfn_limit() && !capable(CAP_SYS_ADMIN))
> +	if (pfn >= l1tf_pfn_limit() && !capable(CAP_SYS_ADMIN))
>  		return false;
>  	return true;
>  }
> -- 
> 2.18.0

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-08-23 13:56 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 [this message]
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
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=20180823135633.GN29735@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --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=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    --cc=xxxxxx@xxxxxx.xxx \
    /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.