License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2008-10-23 13:26:29 +08:00
|
|
|
#ifndef _ASM_X86_TLBFLUSH_H
|
|
|
|
#define _ASM_X86_TLBFLUSH_H
|
2008-01-30 20:30:35 +08:00
|
|
|
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
|
|
|
|
#include <asm/processor.h>
|
2016-01-27 05:12:04 +08:00
|
|
|
#include <asm/cpufeature.h>
|
2012-03-29 01:11:12 +08:00
|
|
|
#include <asm/special_insns.h>
|
2017-05-29 01:00:14 +08:00
|
|
|
#include <asm/smp.h>
|
2008-01-30 20:30:35 +08:00
|
|
|
|
2016-01-30 03:42:57 +08:00
|
|
|
static inline void __invpcid(unsigned long pcid, unsigned long addr,
|
|
|
|
unsigned long type)
|
|
|
|
{
|
2016-02-10 22:51:16 +08:00
|
|
|
struct { u64 d[2]; } desc = { { pcid, addr } };
|
2016-01-30 03:42:57 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The memory clobber is because the whole point is to invalidate
|
|
|
|
* stale TLB entries and, especially if we're flushing global
|
|
|
|
* mappings, we don't want the compiler to reorder any subsequent
|
|
|
|
* memory accesses before the TLB flush.
|
|
|
|
*
|
|
|
|
* The hex opcode is invpcid (%ecx), %eax in 32-bit mode and
|
|
|
|
* invpcid (%rcx), %rax in long mode.
|
|
|
|
*/
|
|
|
|
asm volatile (".byte 0x66, 0x0f, 0x38, 0x82, 0x01"
|
2016-02-10 22:51:16 +08:00
|
|
|
: : "m" (desc), "a" (type), "c" (&desc) : "memory");
|
2016-01-30 03:42:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define INVPCID_TYPE_INDIV_ADDR 0
|
|
|
|
#define INVPCID_TYPE_SINGLE_CTXT 1
|
|
|
|
#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
|
|
|
|
#define INVPCID_TYPE_ALL_NON_GLOBAL 3
|
|
|
|
|
|
|
|
/* Flush all mappings for a given pcid and addr, not including globals. */
|
|
|
|
static inline void invpcid_flush_one(unsigned long pcid,
|
|
|
|
unsigned long addr)
|
|
|
|
{
|
|
|
|
__invpcid(pcid, addr, INVPCID_TYPE_INDIV_ADDR);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings for a given PCID, not including globals. */
|
|
|
|
static inline void invpcid_flush_single_context(unsigned long pcid)
|
|
|
|
{
|
|
|
|
__invpcid(pcid, 0, INVPCID_TYPE_SINGLE_CTXT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings, including globals, for all PCIDs. */
|
|
|
|
static inline void invpcid_flush_all(void)
|
|
|
|
{
|
|
|
|
__invpcid(0, 0, INVPCID_TYPE_ALL_INCL_GLOBAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings for all PCIDs except globals. */
|
|
|
|
static inline void invpcid_flush_all_nonglobals(void)
|
|
|
|
{
|
|
|
|
__invpcid(0, 0, INVPCID_TYPE_ALL_NON_GLOBAL);
|
|
|
|
}
|
|
|
|
|
2017-06-29 23:53:15 +08:00
|
|
|
static inline u64 inc_mm_tlb_gen(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
u64 new_tlb_gen;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bump the generation count. This also serves as a full barrier
|
|
|
|
* that synchronizes with switch_mm(): callers are required to order
|
|
|
|
* their read of mm_cpumask after their writes to the paging
|
|
|
|
* structures.
|
|
|
|
*/
|
|
|
|
smp_mb__before_atomic();
|
|
|
|
new_tlb_gen = atomic64_inc_return(&mm->context.tlb_gen);
|
|
|
|
smp_mb__after_atomic();
|
|
|
|
|
|
|
|
return new_tlb_gen;
|
|
|
|
}
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
#ifdef CONFIG_PARAVIRT
|
|
|
|
#include <asm/paravirt.h>
|
|
|
|
#else
|
|
|
|
#define __flush_tlb() __native_flush_tlb()
|
|
|
|
#define __flush_tlb_global() __native_flush_tlb_global()
|
|
|
|
#define __flush_tlb_single(addr) __native_flush_tlb_single(addr)
|
|
|
|
#endif
|
|
|
|
|
2017-10-15 00:59:50 +08:00
|
|
|
static inline bool tlb_defer_switch_to_init_mm(void)
|
|
|
|
{
|
2017-10-15 00:59:51 +08:00
|
|
|
/*
|
|
|
|
* If we have PCID, then switching to init_mm is reasonably
|
|
|
|
* fast. If we don't have PCID, then switching to init_mm is
|
|
|
|
* quite slow, so we try to defer it in the hopes that we can
|
|
|
|
* avoid it entirely. The latter approach runs the risk of
|
|
|
|
* receiving otherwise unnecessary IPIs.
|
|
|
|
*
|
|
|
|
* This choice is just a heuristic. The tlb code can handle this
|
|
|
|
* function returning true or false regardless of whether we have
|
|
|
|
* PCID.
|
|
|
|
*/
|
|
|
|
return !static_cpu_has(X86_FEATURE_PCID);
|
2017-10-15 00:59:50 +08:00
|
|
|
}
|
x86/mm: Flush more aggressively in lazy TLB mode
Since commit:
94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
x86's lazy TLB mode has been all the way lazy: when running a kernel thread
(including the idle thread), the kernel keeps using the last user mm's
page tables without attempting to maintain user TLB coherence at all.
From a pure semantic perspective, this is fine -- kernel threads won't
attempt to access user pages, so having stale TLB entries doesn't matter.
Unfortunately, I forgot about a subtlety. By skipping TLB flushes,
we also allow any paging-structure caches that may exist on the CPU
to become incoherent. This means that we can have a
paging-structure cache entry that references a freed page table, and
the CPU is within its rights to do a speculative page walk starting
at the freed page table.
I can imagine this causing two different problems:
- A speculative page walk starting from a bogus page table could read
IO addresses. I haven't seen any reports of this causing problems.
- A speculative page walk that involves a bogus page table can install
garbage in the TLB. Such garbage would always be at a user VA, but
some AMD CPUs have logic that triggers a machine check when it notices
these bogus entries. I've seen a couple reports of this.
Boris further explains the failure mode:
> It is actually more of an optimization which assumes that paging-structure
> entries are in WB DRAM:
>
> "TlbCacheDis: cacheable memory disable. Read-write. 0=Enables
> performance optimization that assumes PML4, PDP, PDE, and PTE entries
> are in cacheable WB-DRAM; memory type checks may be bypassed, and
> addresses outside of WB-DRAM may result in undefined behavior or NB
> protocol errors. 1=Disables performance optimization and allows PML4,
> PDP, PDE and PTE entries to be in any memory type. Operating systems
> that maintain page tables in memory types other than WB- DRAM must set
> TlbCacheDis to insure proper operation."
>
> The MCE generated is an NB protocol error to signal that
>
> "Link: A specific coherent-only packet from a CPU was issued to an
> IO link. This may be caused by software which addresses page table
> structures in a memory type other than cacheable WB-DRAM without
> properly configuring MSRC001_0015[TlbCacheDis]. This may occur, for
> example, when page table structure addresses are above top of memory. In
> such cases, the NB will generate an MCE if it sees a mismatch between
> the memory operation generated by the core and the link type."
>
> I'm assuming coherent-only packets don't go out on IO links, thus the
> error.
To fix this, reinstate TLB coherence in lazy mode. With this patch
applied, we do it in one of two ways:
- If we have PCID, we simply switch back to init_mm's page tables
when we enter a kernel thread -- this seems to be quite cheap
except for the cost of serializing the CPU.
- If we don't have PCID, then we set a flag and switch to init_mm
the first time we would otherwise need to flush the TLB.
The /sys/kernel/debug/x86/tlb_use_lazy_mode debug switch can be changed
to override the default mode for benchmarking.
In theory, we could optimize this better by only flushing the TLB in
lazy CPUs when a page table is freed. Doing that would require
auditing the mm code to make sure that all page table freeing goes
through tlb_remove_page() as well as reworking some data structures
to implement the improved flush logic.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Johannes Hirte <johannes.hirte@datenkhaos.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Roman Kagan <rkagan@virtuozzo.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
Link: http://lkml.kernel.org/r/20171009170231.fkpraqokz6e4zeco@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-10 00:50:49 +08:00
|
|
|
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 12:41:38 +08:00
|
|
|
/*
|
|
|
|
* 6 because 6 should be plenty and struct tlb_state will fit in
|
|
|
|
* two cache lines.
|
|
|
|
*/
|
|
|
|
#define TLB_NR_DYN_ASIDS 6
|
|
|
|
|
2017-06-29 23:53:16 +08:00
|
|
|
struct tlb_context {
|
|
|
|
u64 ctx_id;
|
|
|
|
u64 tlb_gen;
|
|
|
|
};
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
struct tlb_state {
|
x86/mm: Rework lazy TLB to track the actual loaded mm
Lazy TLB state is currently managed in a rather baroque manner.
AFAICT, there are three possible states:
- Non-lazy. This means that we're running a user thread or a
kernel thread that has called use_mm(). current->mm ==
current->active_mm == cpu_tlbstate.active_mm and
cpu_tlbstate.state == TLBSTATE_OK.
- Lazy with user mm. We're running a kernel thread without an mm
and we're borrowing an mm_struct. We have current->mm == NULL,
current->active_mm == cpu_tlbstate.active_mm, cpu_tlbstate.state
!= TLBSTATE_OK (i.e. TLBSTATE_LAZY or 0). The current cpu is set
in mm_cpumask(current->active_mm). CR3 points to
current->active_mm->pgd. The TLB is up to date.
- Lazy with init_mm. This happens when we call leave_mm(). We
have current->mm == NULL, current->active_mm ==
cpu_tlbstate.active_mm, but that mm is only relelvant insofar as
the scheduler is tracking it for refcounting. cpu_tlbstate.state
!= TLBSTATE_OK. The current cpu is clear in
mm_cpumask(current->active_mm). CR3 points to swapper_pg_dir,
i.e. init_mm->pgd.
This patch simplifies the situation. Other than perf, x86 stops
caring about current->active_mm at all. We have
cpu_tlbstate.loaded_mm pointing to the mm that CR3 references. The
TLB is always up to date for that mm. leave_mm() just switches us
to init_mm. There are no longer any special cases for mm_cpumask,
and switch_mm() switches mms without worrying about laziness.
After this patch, cpu_tlbstate.state serves only to tell the TLB
flush code whether it may switch to init_mm instead of doing a
normal flush.
This makes fairly extensive changes to xen_exit_mmap(), which used
to look a bit like black magic.
Perf is unchanged. With or without this change, perf may behave a bit
erratically if it tries to read user memory in kernel thread context.
We should build on this patch to teach perf to never look at user
memory when cpu_tlbstate.loaded_mm != current->mm.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Nadav Amit <namit@vmware.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-29 01:00:15 +08:00
|
|
|
/*
|
|
|
|
* cpu_tlbstate.loaded_mm should match CR3 whenever interrupts
|
|
|
|
* are on. This means that it may not match current->active_mm,
|
|
|
|
* which will contain the previous user mm when we're in lazy TLB
|
|
|
|
* mode even if we've already switched back to swapper_pg_dir.
|
|
|
|
*/
|
|
|
|
struct mm_struct *loaded_mm;
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 12:41:38 +08:00
|
|
|
u16 loaded_mm_asid;
|
|
|
|
u16 next_asid;
|
2014-10-25 06:58:08 +08:00
|
|
|
|
x86/mm: Flush more aggressively in lazy TLB mode
Since commit:
94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
x86's lazy TLB mode has been all the way lazy: when running a kernel thread
(including the idle thread), the kernel keeps using the last user mm's
page tables without attempting to maintain user TLB coherence at all.
From a pure semantic perspective, this is fine -- kernel threads won't
attempt to access user pages, so having stale TLB entries doesn't matter.
Unfortunately, I forgot about a subtlety. By skipping TLB flushes,
we also allow any paging-structure caches that may exist on the CPU
to become incoherent. This means that we can have a
paging-structure cache entry that references a freed page table, and
the CPU is within its rights to do a speculative page walk starting
at the freed page table.
I can imagine this causing two different problems:
- A speculative page walk starting from a bogus page table could read
IO addresses. I haven't seen any reports of this causing problems.
- A speculative page walk that involves a bogus page table can install
garbage in the TLB. Such garbage would always be at a user VA, but
some AMD CPUs have logic that triggers a machine check when it notices
these bogus entries. I've seen a couple reports of this.
Boris further explains the failure mode:
> It is actually more of an optimization which assumes that paging-structure
> entries are in WB DRAM:
>
> "TlbCacheDis: cacheable memory disable. Read-write. 0=Enables
> performance optimization that assumes PML4, PDP, PDE, and PTE entries
> are in cacheable WB-DRAM; memory type checks may be bypassed, and
> addresses outside of WB-DRAM may result in undefined behavior or NB
> protocol errors. 1=Disables performance optimization and allows PML4,
> PDP, PDE and PTE entries to be in any memory type. Operating systems
> that maintain page tables in memory types other than WB- DRAM must set
> TlbCacheDis to insure proper operation."
>
> The MCE generated is an NB protocol error to signal that
>
> "Link: A specific coherent-only packet from a CPU was issued to an
> IO link. This may be caused by software which addresses page table
> structures in a memory type other than cacheable WB-DRAM without
> properly configuring MSRC001_0015[TlbCacheDis]. This may occur, for
> example, when page table structure addresses are above top of memory. In
> such cases, the NB will generate an MCE if it sees a mismatch between
> the memory operation generated by the core and the link type."
>
> I'm assuming coherent-only packets don't go out on IO links, thus the
> error.
To fix this, reinstate TLB coherence in lazy mode. With this patch
applied, we do it in one of two ways:
- If we have PCID, we simply switch back to init_mm's page tables
when we enter a kernel thread -- this seems to be quite cheap
except for the cost of serializing the CPU.
- If we don't have PCID, then we set a flag and switch to init_mm
the first time we would otherwise need to flush the TLB.
The /sys/kernel/debug/x86/tlb_use_lazy_mode debug switch can be changed
to override the default mode for benchmarking.
In theory, we could optimize this better by only flushing the TLB in
lazy CPUs when a page table is freed. Doing that would require
auditing the mm code to make sure that all page table freeing goes
through tlb_remove_page() as well as reworking some data structures
to implement the improved flush logic.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Johannes Hirte <johannes.hirte@datenkhaos.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Roman Kagan <rkagan@virtuozzo.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
Link: http://lkml.kernel.org/r/20171009170231.fkpraqokz6e4zeco@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-10 00:50:49 +08:00
|
|
|
/*
|
|
|
|
* We can be in one of several states:
|
|
|
|
*
|
|
|
|
* - Actively using an mm. Our CPU's bit will be set in
|
|
|
|
* mm_cpumask(loaded_mm) and is_lazy == false;
|
|
|
|
*
|
|
|
|
* - Not using a real mm. loaded_mm == &init_mm. Our CPU's bit
|
|
|
|
* will not be set in mm_cpumask(&init_mm) and is_lazy == false.
|
|
|
|
*
|
|
|
|
* - Lazily using a real mm. loaded_mm != &init_mm, our bit
|
|
|
|
* is set in mm_cpumask(loaded_mm), but is_lazy == true.
|
|
|
|
* We're heuristically guessing that the CR3 load we
|
|
|
|
* skipped more than makes up for the overhead added by
|
|
|
|
* lazy mode.
|
|
|
|
*/
|
|
|
|
bool is_lazy;
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
/*
|
|
|
|
* Access to this CR4 shadow and to H/W CR4 is protected by
|
|
|
|
* disabling interrupts when modifying either one.
|
|
|
|
*/
|
|
|
|
unsigned long cr4;
|
2017-06-29 23:53:16 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a list of all contexts that might exist in the TLB.
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 12:41:38 +08:00
|
|
|
* There is one per ASID that we use, and the ASID (what the
|
|
|
|
* CPU calls PCID) is the index into ctxts.
|
2017-06-29 23:53:16 +08:00
|
|
|
*
|
|
|
|
* For each context, ctx_id indicates which mm the TLB's user
|
|
|
|
* entries came from. As an invariant, the TLB will never
|
|
|
|
* contain entries that are out-of-date as when that mm reached
|
|
|
|
* the tlb_gen in the list.
|
|
|
|
*
|
|
|
|
* To be clear, this means that it's legal for the TLB code to
|
|
|
|
* flush the TLB without updating tlb_gen. This can happen
|
|
|
|
* (for now, at least) due to paravirt remote flushes.
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 12:41:38 +08:00
|
|
|
*
|
|
|
|
* NB: context 0 is a bit special, since it's also used by
|
|
|
|
* various bits of init code. This is fine -- code that
|
|
|
|
* isn't aware of PCID will end up harmlessly flushing
|
|
|
|
* context 0.
|
2017-06-29 23:53:16 +08:00
|
|
|
*/
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 12:41:38 +08:00
|
|
|
struct tlb_context ctxs[TLB_NR_DYN_ASIDS];
|
2014-10-25 06:58:08 +08:00
|
|
|
};
|
|
|
|
DECLARE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate);
|
|
|
|
|
|
|
|
/* Initialize cr4 shadow for this CPU. */
|
|
|
|
static inline void cr4_init_shadow(void)
|
|
|
|
{
|
2016-09-30 03:48:12 +08:00
|
|
|
this_cpu_write(cpu_tlbstate.cr4, __read_cr4());
|
2014-10-25 06:58:08 +08:00
|
|
|
}
|
|
|
|
|
2014-10-25 06:58:07 +08:00
|
|
|
/* Set in this cpu's CR4. */
|
|
|
|
static inline void cr4_set_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
if ((cr4 | mask) != cr4) {
|
|
|
|
cr4 |= mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
2014-10-25 06:58:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear in this cpu's CR4. */
|
|
|
|
static inline void cr4_clear_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
if ((cr4 & ~mask) != cr4) {
|
|
|
|
cr4 &= ~mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-14 16:11:04 +08:00
|
|
|
static inline void cr4_toggle_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
cr4 ^= mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
/* Read the CR4 shadow. */
|
|
|
|
static inline unsigned long cr4_read_shadow(void)
|
|
|
|
{
|
|
|
|
return this_cpu_read(cpu_tlbstate.cr4);
|
2014-10-25 06:58:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Save some of cr4 feature set we're using (e.g. Pentium 4MB
|
|
|
|
* enable and PPro Global page enable), so that any CPU's that boot
|
|
|
|
* up after us can get the correct flags. This should only be used
|
|
|
|
* during boot on the boot cpu.
|
|
|
|
*/
|
|
|
|
extern unsigned long mmu_cr4_features;
|
|
|
|
extern u32 *trampoline_cr4_features;
|
|
|
|
|
|
|
|
static inline void cr4_set_bits_and_update_boot(unsigned long mask)
|
|
|
|
{
|
|
|
|
mmu_cr4_features |= mask;
|
|
|
|
if (trampoline_cr4_features)
|
|
|
|
*trampoline_cr4_features = mmu_cr4_features;
|
|
|
|
cr4_set_bits(mask);
|
|
|
|
}
|
|
|
|
|
2017-09-07 10:54:53 +08:00
|
|
|
extern void initialize_tlbstate_and_flush(void);
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
static inline void __native_flush_tlb(void)
|
|
|
|
{
|
2016-08-05 21:37:39 +08:00
|
|
|
/*
|
|
|
|
* If current->mm == NULL then we borrow a mm which may change during a
|
|
|
|
* task switch and therefore we must not be preempted while we write CR3
|
|
|
|
* back:
|
|
|
|
*/
|
|
|
|
preempt_disable();
|
2017-06-13 01:26:14 +08:00
|
|
|
native_write_cr3(__native_read_cr3());
|
2016-08-05 21:37:39 +08:00
|
|
|
preempt_enable();
|
2008-01-30 20:30:35 +08:00
|
|
|
}
|
|
|
|
|
2012-12-21 15:44:27 +08:00
|
|
|
static inline void __native_flush_tlb_global_irq_disabled(void)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 06:58:08 +08:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
2012-12-21 15:44:27 +08:00
|
|
|
/* clear PGE */
|
|
|
|
native_write_cr4(cr4 & ~X86_CR4_PGE);
|
|
|
|
/* write old PGE again and flush TLBs */
|
|
|
|
native_write_cr4(cr4);
|
|
|
|
}
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
static inline void __native_flush_tlb_global(void)
|
|
|
|
{
|
2008-05-13 03:21:15 +08:00
|
|
|
unsigned long flags;
|
2008-01-30 20:30:35 +08:00
|
|
|
|
2016-01-30 03:42:59 +08:00
|
|
|
if (static_cpu_has(X86_FEATURE_INVPCID)) {
|
|
|
|
/*
|
|
|
|
* Using INVPCID is considerably faster than a pair of writes
|
|
|
|
* to CR4 sandwiched inside an IRQ flag save/restore.
|
|
|
|
*/
|
|
|
|
invpcid_flush_all();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-05-13 03:21:15 +08:00
|
|
|
/*
|
|
|
|
* Read-modify-write to CR4 - protect it from preemption and
|
|
|
|
* from interrupts. (Use the raw variant because this code can
|
|
|
|
* be called from deep inside debugging code.)
|
|
|
|
*/
|
|
|
|
raw_local_irq_save(flags);
|
|
|
|
|
2012-12-21 15:44:27 +08:00
|
|
|
__native_flush_tlb_global_irq_disabled();
|
2008-05-13 03:21:15 +08:00
|
|
|
|
|
|
|
raw_local_irq_restore(flags);
|
2008-01-30 20:30:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __native_flush_tlb_single(unsigned long addr)
|
|
|
|
{
|
2008-03-23 16:03:45 +08:00
|
|
|
asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
|
2008-01-30 20:30:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __flush_tlb_all(void)
|
|
|
|
{
|
x86/tlb: Fix tlb flushing when lguest clears PGE
Fengguang reported random corruptions from various locations on x86-32
after commits d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY config") and
9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set")
that uses the former. While x86-32 doesn't have a JIT like x86_64, the
bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to
ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module
support built in and therefore never had the DEBUG_SET_MODULE_RONX setting
enabled.
After investigating the crashes further, it turned out that using
set_memory_ro() and set_memory_rw() didn't have the desired effect, for
example, setting the pages as read-only on x86-32 would still let
probe_kernel_write() succeed without error. This behavior would manifest
itself in situations where the vmalloc'ed buffer was accessed prior to
set_memory_*() such as in case of bpf_prog_alloc(). In cases where it
wasn't, the page attribute changes seemed to have taken effect, leading to
the conclusion that a TLB invalidate didn't happen. Moreover, it turned out
that this issue reproduced with qemu in "-cpu kvm64" mode, but not for
"-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger
a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(),
though.
There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends
on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush
(depends on X86_FEATURE_PGE), and cr3 based flush. For "-cpu host" case in
my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu
kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually
worked fine, and further investigating the cr4 one turned out that
X86_CR4_PGE bit was not set in cr4 register, meaning the
__native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same
value instead of clearing X86_CR4_PGE in the first write to trigger the
flush.
It turned out that X86_CR4_PGE was cleared from cr4 during init from
lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also
cleared from there due to concerns of using PGE in guest kernel that can
lead to hard to trace bugs (see bff672e630a0 ("lguest: documentation V:
Host") in init()). The CPU feature bits are cleared in dynamic
boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses
static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB
flushing to use, meaning they still used the old setting of the host
kernel.
Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate
to static_cpu_has() checks is too late at this point as sections have been
patched already, so for now, it seems reasonable to switch back to
boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95992b
("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via
cr3 as originally intended, properly makes the new page attributes visible
and thus fixes the crashes seen by Fengguang.
Fixes: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: bp@suse.de
Cc: Kees Cook <keescook@chromium.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: lkp@01.org
Cc: Laura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com
Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-11 08:31:19 +08:00
|
|
|
if (boot_cpu_has(X86_FEATURE_PGE))
|
2008-01-30 20:30:35 +08:00
|
|
|
__flush_tlb_global();
|
|
|
|
else
|
|
|
|
__flush_tlb();
|
2017-06-29 23:53:21 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: if we somehow had PCID but not PGE, then this wouldn't work --
|
|
|
|
* we'd end up flushing kernel translations for the current ASID but
|
|
|
|
* we might fail to flush kernel translations for other cached ASIDs.
|
|
|
|
*
|
|
|
|
* To avoid this issue, we force PCID off if PGE is off.
|
|
|
|
*/
|
2008-01-30 20:30:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __flush_tlb_one(unsigned long addr)
|
|
|
|
{
|
2014-01-22 06:33:16 +08:00
|
|
|
count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ONE);
|
2013-06-04 14:28:18 +08:00
|
|
|
__flush_tlb_single(addr);
|
2008-01-30 20:30:35 +08:00
|
|
|
}
|
|
|
|
|
2012-05-10 18:01:59 +08:00
|
|
|
#define TLB_FLUSH_ALL -1UL
|
2008-01-30 20:30:35 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* TLB flushing:
|
|
|
|
*
|
|
|
|
* - flush_tlb_all() flushes all processes TLBs
|
|
|
|
* - flush_tlb_mm(mm) flushes the specified mm context TLB's
|
|
|
|
* - flush_tlb_page(vma, vmaddr) flushes one page
|
|
|
|
* - flush_tlb_range(vma, start, end) flushes a range of pages
|
|
|
|
* - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
|
2017-05-29 01:00:10 +08:00
|
|
|
* - flush_tlb_others(cpumask, info) flushes TLBs on other cpus
|
2008-01-30 20:30:35 +08:00
|
|
|
*
|
|
|
|
* ..but the i386 has somewhat limited tlb flushing capabilities,
|
|
|
|
* and page-granular flushes are available only on i486 and up.
|
|
|
|
*/
|
2017-05-29 01:00:10 +08:00
|
|
|
struct flush_tlb_info {
|
2017-06-29 23:53:16 +08:00
|
|
|
/*
|
|
|
|
* We support several kinds of flushes.
|
|
|
|
*
|
|
|
|
* - Fully flush a single mm. .mm will be set, .end will be
|
|
|
|
* TLB_FLUSH_ALL, and .new_tlb_gen will be the tlb_gen to
|
|
|
|
* which the IPI sender is trying to catch us up.
|
|
|
|
*
|
|
|
|
* - Partially flush a single mm. .mm will be set, .start and
|
|
|
|
* .end will indicate the range, and .new_tlb_gen will be set
|
|
|
|
* such that the changes between generation .new_tlb_gen-1 and
|
|
|
|
* .new_tlb_gen are entirely contained in the indicated range.
|
|
|
|
*
|
|
|
|
* - Fully flush all mms whose tlb_gens have been updated. .mm
|
|
|
|
* will be NULL, .end will be TLB_FLUSH_ALL, and .new_tlb_gen
|
|
|
|
* will be zero.
|
|
|
|
*/
|
|
|
|
struct mm_struct *mm;
|
|
|
|
unsigned long start;
|
|
|
|
unsigned long end;
|
|
|
|
u64 new_tlb_gen;
|
2017-05-29 01:00:10 +08:00
|
|
|
};
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
#define local_flush_tlb() __flush_tlb()
|
|
|
|
|
x86/tlb: enable tlb flush range support for x86
Not every tlb_flush execution moment is really need to evacuate all
TLB entries, like in munmap, just few 'invlpg' is better for whole
process performance, since it leaves most of TLB entries for later
accessing.
This patch also rewrite flush_tlb_range for 2 purposes:
1, split it out to get flush_blt_mm_range function.
2, clean up to reduce line breaking, thanks for Borislav's input.
My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59
show that the random memory access on other CPU has 0~50% speed up
on a 2P * 4cores * HT NHM EP while do 'munmap'.
Thanks Yongjie's testing on this patch:
-------------
I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest
kernel.
After running two benchmarks in Xen HVM guest, I found his patches
brought about 1%~3% performance gain in 'kernel build' and 'netperf'
testing, though the performance gain was not very stable in 'kernel
build' testing.
Some detailed testing results are below.
Testing Environment:
Hardware: Romley-EP platform
Xen version: latest upstream
Linux kernel: 3.4-RC6
Guest vCPU number: 8
NIC: Intel 82599 (10GB bandwidth)
In 'kernel build' testing in guest:
Command line | performance gain
make -j 4 | 3.81%
make -j 8 | 0.37%
make -j 16 | -0.52%
In 'netperf' testing, we tested TCP_STREAM with default socket size
16384 byte as large packet and 64 byte as small packet.
I used several clients to add networking pressure, then 'netperf' server
automatically generated several threads to response them.
I also used large-size packet and small-size packet in the testing.
Packet size | Thread number | performance gain
16384 bytes | 4 | 0.02%
16384 bytes | 8 | 2.21%
16384 bytes | 16 | 2.04%
64 bytes | 4 | 1.07%
64 bytes | 8 | 3.31%
64 bytes | 16 | 0.71%
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-8-git-send-email-alex.shi@intel.com
Tested-by: Ren, Yongjie <yongjie.ren@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 09:02:22 +08:00
|
|
|
#define flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL)
|
|
|
|
|
|
|
|
#define flush_tlb_range(vma, start, end) \
|
|
|
|
flush_tlb_mm_range(vma->vm_mm, start, end, vma->vm_flags)
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
extern void flush_tlb_all(void);
|
x86/tlb: enable tlb flush range support for x86
Not every tlb_flush execution moment is really need to evacuate all
TLB entries, like in munmap, just few 'invlpg' is better for whole
process performance, since it leaves most of TLB entries for later
accessing.
This patch also rewrite flush_tlb_range for 2 purposes:
1, split it out to get flush_blt_mm_range function.
2, clean up to reduce line breaking, thanks for Borislav's input.
My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59
show that the random memory access on other CPU has 0~50% speed up
on a 2P * 4cores * HT NHM EP while do 'munmap'.
Thanks Yongjie's testing on this patch:
-------------
I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest
kernel.
After running two benchmarks in Xen HVM guest, I found his patches
brought about 1%~3% performance gain in 'kernel build' and 'netperf'
testing, though the performance gain was not very stable in 'kernel
build' testing.
Some detailed testing results are below.
Testing Environment:
Hardware: Romley-EP platform
Xen version: latest upstream
Linux kernel: 3.4-RC6
Guest vCPU number: 8
NIC: Intel 82599 (10GB bandwidth)
In 'kernel build' testing in guest:
Command line | performance gain
make -j 4 | 3.81%
make -j 8 | 0.37%
make -j 16 | -0.52%
In 'netperf' testing, we tested TCP_STREAM with default socket size
16384 byte as large packet and 64 byte as small packet.
I used several clients to add networking pressure, then 'netperf' server
automatically generated several threads to response them.
I also used large-size packet and small-size packet in the testing.
Packet size | Thread number | performance gain
16384 bytes | 4 | 0.02%
16384 bytes | 8 | 2.21%
16384 bytes | 16 | 2.04%
64 bytes | 4 | 1.07%
64 bytes | 8 | 3.31%
64 bytes | 16 | 0.71%
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-8-git-send-email-alex.shi@intel.com
Tested-by: Ren, Yongjie <yongjie.ren@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 09:02:22 +08:00
|
|
|
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
|
|
|
|
unsigned long end, unsigned long vmflag);
|
2012-06-28 09:02:24 +08:00
|
|
|
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
|
2008-01-30 20:30:35 +08:00
|
|
|
|
2017-05-23 06:30:01 +08:00
|
|
|
static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
|
|
|
|
{
|
|
|
|
flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, VM_NONE);
|
|
|
|
}
|
|
|
|
|
2009-01-11 13:58:09 +08:00
|
|
|
void native_flush_tlb_others(const struct cpumask *cpumask,
|
2017-05-29 01:00:10 +08:00
|
|
|
const struct flush_tlb_info *info);
|
2008-01-30 20:30:35 +08:00
|
|
|
|
2017-05-23 06:30:03 +08:00
|
|
|
static inline void arch_tlbbatch_add_mm(struct arch_tlbflush_unmap_batch *batch,
|
|
|
|
struct mm_struct *mm)
|
|
|
|
{
|
2017-06-29 23:53:15 +08:00
|
|
|
inc_mm_tlb_gen(mm);
|
2017-05-23 06:30:03 +08:00
|
|
|
cpumask_or(&batch->cpumask, &batch->cpumask, mm_cpumask(mm));
|
|
|
|
}
|
|
|
|
|
|
|
|
extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
|
|
|
|
|
2008-01-30 20:30:35 +08:00
|
|
|
#ifndef CONFIG_PARAVIRT
|
2017-05-29 01:00:10 +08:00
|
|
|
#define flush_tlb_others(mask, info) \
|
|
|
|
native_flush_tlb_others(mask, info)
|
2007-10-11 17:20:03 +08:00
|
|
|
#endif
|
2008-01-30 20:30:35 +08:00
|
|
|
|
2008-10-23 13:26:29 +08:00
|
|
|
#endif /* _ASM_X86_TLBFLUSH_H */
|