[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171205212727.GU3165@worktop.lehotels.local>
Date: Tue, 5 Dec 2017 22:27:27 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Andrew Banman <abanman@....com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirsky <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>,
Borislav Petkov <bpetkov@...e.de>,
Greg KH <gregkh@...uxfoundation.org>, keescook@...gle.com,
hughd@...gle.com, Brian Gerst <brgerst@...il.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Rik van Riel <riel@...hat.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
David Laight <David.Laight@...lab.com>,
Eduardo Valentin <eduval@...zon.com>, aliguori@...zon.com,
Will Deacon <will.deacon@....com>, daniel.gruss@...k.tugraz.at,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>, moritz.lipp@...k.tugraz.at,
linux-mm@...ck.org, Borislav Petkov <bp@...en8.de>,
michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
Mike Travis <mike.travis@....com>
Subject: Re: [PATCH 5/9] x86/uv: Use the right tlbflush API
On Tue, Dec 05, 2017 at 03:09:48PM -0600, Andrew Banman wrote:
> On 12/5/17 6:34 AM, Peter Zijlstra wrote:
> >Since uv_flush_tlb_others() implements flush_tlb_others() which is
> >about flushing user mappings, we should use __flush_tlb_single(),
> >which too is about flushing user mappings.
> >
> >Cc: Andrew Banman<abanman@....com>
> >Cc: Mike Travis<mike.travis@....com>
> >Signed-off-by: Peter Zijlstra (Intel)<peterz@...radead.org>
> >---
> > arch/x86/platform/uv/tlb_uv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >--- a/arch/x86/platform/uv/tlb_uv.c
> >+++ b/arch/x86/platform/uv/tlb_uv.c
> >@@ -299,7 +299,7 @@ static void bau_process_message(struct m
> > local_flush_tlb();
> > stat->d_alltlb++;
> > } else {
> >- __flush_tlb_one(msg->address);
> >+ __flush_tlb_single(msg->address);
> > stat->d_onetlb++;
> > }
> > stat->d_requestee++;
>
> This looks like the right thing to do. We'll be testing it and complain later if
> we find any problems, but I'm not expecting any since this patch looks to
> maintain our status quo.
Well, with KPTI (the-patch-set-formerly-known-as-kaiser), there will be
a distinct difference between the two.
With KPTI __flush_tlb_one() would end up invalidating all kernel
mappings while __flush_tlb_single() will end up only invalidating the
user mappings of the current mm.
Powered by blists - more mailing lists