From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 4D8616B02E1 for ; Tue, 28 Nov 2017 04:57:00 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id x202so31504644pgx.1 for ; Tue, 28 Nov 2017 01:57:00 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com. [192.55.52.88]) by mx.google.com with ESMTPS id n65si12451324pfg.62.2017.11.28.01.56.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 01:56:59 -0800 (PST) Subject: [PATCH] x86/mm/kaiser: Flush the correct ASID in __native_flush_tlb_single() From: Dave Hansen Date: Tue, 28 Nov 2017 01:55:31 -0800 Message-Id: <20171128095531.F32E1BC7@viggo.jf.intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen , "Reported-by:fengguang.wu"@intel.com, tglx@linutronix.de, richard.fellner@student.tugraz.at, moritz.lipp@iaik.tugraz.at, daniel.gruss@iaik.tugraz.at, michael.schwarz@iaik.tugraz.at, luto@kernel.org, torvalds@linux-foundation.org, keescook@google.com, hughd@google.com, bp@alien8.de, x86@kernel.org I believe this fixes a bug introduced in the following KAISER patch: x86/mm/kaiser: Use PCID feature to make user and kernel switches faster It's only been lightly tested. I'm sharing so that folks who might be running into it have a fix to test. -- From: Dave Hansen There have been a series of weird warnings and boot problems on when running the KAISER PCID patches. I believe many of them can be tracked down to this problem. One example: http://lkml.kernel.org/r/5a1aaa36.CWNgvwmmRFzeAlPc%fengguang.wu@intel.com The issue is when we are relatively early in boot and have the lower 12 bits of CR3 clear and thus are running with PCID (aka ASID) 0. cpu_tlbstate.loaded_mm_asid contains a 0. *But* PCID 0 is not ASID 0. The ASIDs are biased up by one as not to conflict with the somewhat special hardware PCID 0. Upon entering __native_flush_tlb_single(), we set loaded_mm_asid=0. We then calculate the kern_asid(), biasing up by 1, get 1, and pass *that* to INVPCID. Thus, we have PCID 0 loaded in CR3 but are flushing PCID 1 with INVPCID. That obviously does not work. To fix this, mark the cpu_tlbstate.loaded_mm_asid as invalid, then detect that state in __native_flush_tlb_single(), falling back to INVLPG. Also add a VM_WARN_ON() to help find these in the future. Signed-off-by: Dave Hansen Reported-by: fengguang.wu@intel.com Cc: Thomas Gleixner Cc: Richard Fellner Cc: Moritz Lipp Cc: Daniel Gruss Cc: Michael Schwarz Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Kees Cook Cc: Hugh Dickins Cc: Borislav Petkov Cc: x86@kernel.org --- b/arch/x86/include/asm/tlbflush.h | 36 +++++++++++++++++++++++++++++++----- b/arch/x86/mm/init.c | 1 + 2 files changed, 32 insertions(+), 5 deletions(-) diff -puN arch/x86/include/asm/tlbflush.h~kaiser-fix-wrong-asid-flush arch/x86/include/asm/tlbflush.h --- a/arch/x86/include/asm/tlbflush.h~kaiser-fix-wrong-asid-flush 2017-11-28 01:43:05.180452966 -0800 +++ b/arch/x86/include/asm/tlbflush.h 2017-11-28 01:43:05.190452966 -0800 @@ -77,6 +77,8 @@ static inline u64 inc_mm_tlb_gen(struct /* There are 12 bits of space for ASIDS in CR3 */ #define CR3_HW_ASID_BITS 12 +#define CR3_NR_HW_ASIDS (1< email@kvack.org