From: Andy Lutomirski <luto@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
X86 ML <x86@kernel.org>, Andrew Lutomirski <luto@kernel.org>
Subject: Re: [PATCH] x86, mm: make alternatives code do stronger TLB flush
Date: Wed, 1 Nov 2017 01:12:24 -0700 [thread overview]
Message-ID: <CALCETrVw5nJoK99FQ+n4SiJPKEQ6umDBYat9zesaxFLLcE+yZg@mail.gmail.com> (raw)
In-Reply-To: <20171031180757.8B5DA496@viggo.jf.intel.com>
On Tue, Oct 31, 2017 at 11:07 AM, Dave Hansen
<dave.hansen@linux.intel.com> wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> local_flush_tlb() does a CR3 write. But, that kind of TLB flush is
> not guaranteed to invalidate global pages. The entire kernel is
> mapped with global pages.
>
> Also, now that we have PCIDs, local_flush_tlb() will only flush the
> *current* PCID. It would not flush the entries for all PCIDs.
> At the moment, this is a moot point because all kernel pages are
> _PAGE_GLOBAL which do not really *have* a particular PCID.
>
> Use the stronger __flush_tlb_all() which does flush global pages.
>
> This was found because of a warning I added to __native_flush_tlb()
> to look for calls to it when PCIDs are enabled. This patch does
> not fix any bug known to be hit in practice.
I'm very confused here. set_fixmap() does a flush. clear_fixmap()
calls set_fixmap() and therefore also flushes. So I don't see why the
flush you're modifying is needed at all. Could you just delete it
instead?
If your KAISER series were applied, then the situation is slightly
different. We have this code:
static void __set_pte_vaddr(pud_t *pud, unsigned long vaddr, pte_t new_pte)
{
pmd_t *pmd = fill_pmd(pud, vaddr);
pte_t *pte = fill_pte(pmd, vaddr);
set_pte(pte, new_pte);
/*
* It's enough to flush this one mapping.
* (PGE mappings get flushed as well)
*/
__flush_tlb_one(vaddr);
}
and that is no longer correct. You may need to add a helper
__flush_tlb_kernel_one() that does the right thing. For the
alternatives case, you could skip it since you know that the mapping
never got propagated to any other PCID slot on the current CPU, but
that's probably not worth trying to optimize.
--Andy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2017-11-01 8:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 18:07 Dave Hansen
2017-11-01 8:12 ` Andy Lutomirski [this message]
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=CALCETrVw5nJoK99FQ+n4SiJPKEQ6umDBYat9zesaxFLLcE+yZg@mail.gmail.com \
--to=luto@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox