Andy Lutomirski
20bb83443e
x86/entry/64: Stop initializing TSS.sp0 at boot
...
In my quest to get rid of thread_struct::sp0, I want to clean up or
remove all of its readers. Two of them are in cpu_init() (32-bit and
64-bit), and they aren't needed. This is because we never enter
userspace at all on the threads that CPUs are initialized in.
Poison the initial TSS.sp0 and stop initializing it on CPU init.
The comment text mostly comes from Dave Hansen. Thanks!
Signed-off-by: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bpetkov@suse.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Dave Hansen <dave.hansen@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/ee4a00540ad28c6cff475fbcc7769a4460acc861.1509609304.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 11:04:46 +01:00
Andy Lutomirski
da51da189a
x86/entry/64: Pass SP0 directly to load_sp0()
...
load_sp0() had an odd signature:
void load_sp0(struct tss_struct *tss, struct thread_struct *thread);
Simplify it to:
void load_sp0(unsigned long sp0);
Also simplify a few get_cpu()/put_cpu() sequences to
preempt_disable()/preempt_enable().
Signed-off-by: Andy Lutomirski <luto@kernel.org >
Reviewed-by: Borislav Petkov <bp@suse.de >
Cc: Borislav Petkov <bpetkov@suse.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Dave Hansen <dave.hansen@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/2655d8b42ed940aa384fe18ee1129bbbcf730a08.1509609304.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 11:04:44 +01:00
Andy Lutomirski
bd7dc5a6af
x86/entry/32: Pull the MSR_IA32_SYSENTER_CS update code out of native_load_sp0()
...
This causes the MSR_IA32_SYSENTER_CS write to move out of the
paravirt callback. This shouldn't affect Xen PV: Xen already ignores
MSR_IA32_SYSENTER_ESP writes. In any event, Xen doesn't support
vm86() in a useful way.
Note to any potential backporters: This patch won't break lguest, as
lguest didn't have any SYSENTER support at all.
Signed-off-by: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bpetkov@suse.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Dave Hansen <dave.hansen@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/75cf09fe03ae778532d0ca6c65aa58e66bc2f90c.1509609304.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 11:04:43 +01:00
Andy Lutomirski
26c4ef9c49
x86/entry/64: Split the IRET-to-user and IRET-to-kernel paths
...
These code paths will diverge soon.
Signed-off-by: Andy Lutomirski <luto@kernel.org >
Cc: Borislav Petkov <bpetkov@suse.de >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Dave Hansen <dave.hansen@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/dccf8c7b3750199b4b30383c812d4e2931811509.1509609304.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 11:04:37 +01:00
Ingo Molnar
50da9d4393
Merge branch 'x86/fpu' into x86/asm
...
We are about to commit complex rework of various x86 entry code details - create
a unified base tree (with FPU commits included) before doing that.
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 10:58:29 +01:00
Ingo Molnar
3357b0d3c7
Merge branch 'x86/mpx/prep' into x86/asm
...
Pick up some of the MPX commits that modify the syscall entry code,
to have a common base and to reduce conflicts.
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-11-02 10:57:24 +01:00
Ricardo Neri
ed40a10431
uprobes/x86: Use existing definitions for segment override prefixes
...
Rather than using hard-coded values of the segment override prefixes,
leverage the existing definitions provided in inat.h.
Suggested-by: Borislav Petkov <bp@suse.de >
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Borislav Petkov <bp@suse.de >
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com >
Cc: "Michael S. Tsirkin" <mst@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: ricardo.neri@intel.com
Cc: Paul Gortmaker <paul.gortmaker@windriver.com >
Cc: Huang Rui <ray.huang@amd.com >
Cc: Shuah Khan <shuah@kernel.org >
Cc: Jonathan Corbet <corbet@lwn.net >
Cc: Jiri Slaby <jslaby@suse.cz >
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: Chris Metcalf <cmetcalf@mellanox.com >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Chen Yucong <slaoub@gmail.com >
Cc: Vlastimil Babka <vbabka@suse.cz >
Cc: Masami Hiramatsu <mhiramat@kernel.org >
Cc: Paolo Bonzini <pbonzini@redhat.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Link: https://lkml.kernel.org/r/1509135945-13762-5-git-send-email-ricardo.neri-calderon@linux.intel.com
2017-11-01 21:50:08 +01:00
Ricardo Neri
b0ce5b8c95
x86/boot: Relocate definition of the initial state of CR0
...
Both head_32.S and head_64.S utilize the same value to initialize the
control register CR0. Also, other parts of the kernel might want to access
this initial definition (e.g., emulation code for User-Mode Instruction
Prevention uses this state to provide a sane dummy value for CR0 when
emulating the smsw instruction). Thus, relocate this definition to a
header file from which it can be conveniently accessed.
Suggested-by: Borislav Petkov <bp@alien8.de >
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Borislav Petkov <bp@suse.de >
Reviewed-by: Andy Lutomirski <luto@kernel.org >
Cc: "Michael S. Tsirkin" <mst@redhat.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Dave Hansen <dave.hansen@linux.intel.com >
Cc: ricardo.neri@intel.com
Cc: linux-mm@kvack.org
Cc: Paul Gortmaker <paul.gortmaker@windriver.com >
Cc: Huang Rui <ray.huang@amd.com >
Cc: Shuah Khan <shuah@kernel.org >
Cc: linux-arch@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net >
Cc: Jiri Slaby <jslaby@suse.cz >
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com >
Cc: Denys Vlasenko <dvlasenk@redhat.com >
Cc: Chris Metcalf <cmetcalf@mellanox.com >
Cc: Brian Gerst <brgerst@gmail.com >
Cc: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Chen Yucong <slaoub@gmail.com >
Cc: Vlastimil Babka <vbabka@suse.cz >
Cc: Dave Hansen <dave.hansen@intel.com >
Cc: Andy Lutomirski <luto@amacapital.net >
Cc: Masami Hiramatsu <mhiramat@kernel.org >
Cc: Paolo Bonzini <pbonzini@redhat.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Link: https://lkml.kernel.org/r/1509135945-13762-3-git-send-email-ricardo.neri-calderon@linux.intel.com
2017-11-01 21:50:07 +01:00
Borislav Petkov
7298f08ea8
x86/mcelog: Get rid of RCU remnants
...
Jeremy reported a suspicious RCU usage warning in mcelog.
/dev/mcelog is called in process context now as part of the notifier
chain and doesn't need any of the fancy RCU and lockless accesses which
it did in atomic context.
Axe it all in favor of a simple mutex synchronization which cures the
problem reported.
Fixes: 5de97c9f6djcline@redhat.com >
Signed-off-by: Borislav Petkov <bp@suse.de >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-and-tested-by: Tony Luck <tony.luck@intel.com >
Cc: Andi Kleen <ak@linux.intel.com >
Cc: linux-edac@vger.kernel.org
Cc: Laura Abbott <labbott@redhat.com >
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969
2017-11-01 21:24:36 +01:00
Gayatri Kammela
c128dbfa0f
x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features
...
Add a few new SSE/AVX/AVX512 instruction groups/features for enumeration
in /proc/cpuinfo: AVX512_VBMI2, GFNI, VAES, VPCLMULQDQ, AVX512_VNNI,
AVX512_BITALG.
CPUID.(EAX=7,ECX=0):ECX[bit 6] AVX512_VBMI2
CPUID.(EAX=7,ECX=0):ECX[bit 8] GFNI
CPUID.(EAX=7,ECX=0):ECX[bit 9] VAES
CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512_VNNI
CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
Detailed information of CPUID bits for these features can be found
in the Intel Architecture Instruction Set Extensions and Future Features
Programming Interface document (refer to Table 1-1. and Table 1-2.).
A copy of this document is available at
https://bugzilla.kernel.org/show_bug.cgi?id=197239
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com >
Acked-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Andi Kleen <andi.kleen@intel.com >
Cc: Fenghua Yu <fenghua.yu@intel.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Ravi Shankar <ravi.v.shankar@intel.com >
Cc: Ricardo Neri <ricardo.neri@intel.com >
Cc: Yang Zhong <yang.zhong@intel.com >
Cc: bp@alien8.de
Link: http://lkml.kernel.org/r/1509412829-23380-1-git-send-email-gayatri.kammela@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-31 11:02:26 +01:00
Ingo Molnar
e17bae3266
Merge tag 'v4.14-rc7' into x86/mm, to pick up fixes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-30 10:30:09 +01:00
Dou Liyang
ca5d376e17
x86/paravirt: Set up the virt_spin_lock_key after static keys get initialized
...
Commit:
9043442b43jgross@suse.com >
Reported-by: Juergen Gross <jgross@suse.com >
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com >
Reviewed-by: Juergen Gross <jgross@suse.com >
Acked-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: boris.ostrovsky@oracle.com
Cc: bp@suse.de
Cc: luto@kernel.org
Cc: vkuznets@redhat.com
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1509170804-3813-1-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-30 09:17:29 +01:00
Ingo Molnar
6856b8e536
Merge branch 'perf/urgent' into perf/core, to pick up fixes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-27 10:31:44 +02:00
Mark Rutland
6aa7de0591
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
...
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com >
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-25 11:01:08 +02:00
Will Deacon
506458efaf
locking/barriers: Convert users of lockless_dereference() to READ_ONCE()
...
READ_ONCE() now has an implicit smp_read_barrier_depends() call, so it
can be used instead of lockless_dereference() without any change in
semantics.
Signed-off-by: Will Deacon <will.deacon@arm.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/1508840570-22169-4-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-24 13:17:33 +02:00
Ingo Molnar
9babb091e0
Merge tag 'v4.14-rc6' into locking/core, to pick up fixes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-24 13:17:20 +02:00
mike.travis@hpe.com
b3270a5210
x86/platform/UV: Mark tsc_check_sync as an init function
...
Fix build problem:
>> WARNING: vmlinux.o(.text+0x4223a): Section mismatch in
reference from the function uv_tsc_check_sync() to the function
.init.text:uv_early_read_mmr() The function uv_tsc_check_sync()
references the function __init uv_early_read_mmr(). This is often
because uv_tsc_check_sync lacks a __init
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Cc: Russ Anderson <russ.anderson@hpe.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171023191841.985614692@stormcage.americas.sgi.com
2017-10-24 09:10:51 +02:00
Josh Poimboeuf
82c62fa0c4
x86/asm: Don't use the confusing '.ifeq' directive
...
I find the '.ifeq <expression>' directive to be confusing. Reading it
quickly seems to suggest its opposite meaning, or that it's missing an
argument.
Improve readability by replacing all of its x86 uses with
'.if <expression> == 0'.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Andrei Vagin <avagin@virtuozzo.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/757da028e802c7e98d23fbab8d234b1063e161cf.1508516398.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-23 13:31:34 +02:00
Ingo Molnar
bae9525531
Merge branch 'core/objtool' into x86/asm, to pick up dependent changes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-23 13:31:17 +02:00
Ingo Molnar
f95b23a112
Merge branch 'x86/urgent' into x86/asm, to pick up dependent fixes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-23 13:30:47 +02:00
Josh Poimboeuf
58c3862b52
x86/unwind: Show function name+offset in ORC error messages
...
Improve the warning messages to show the relevant function name+offset.
This makes it much easier to diagnose problems with the ORC metadata.
Before:
WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
After:
WARNING: can't dereference iret registers at ffff880178f5ffe0 for ip int3+0x5b/0x60
Reported-by: Andrei Vagin <avagin@virtuozzo.com >
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Andy Lutomirski <luto@kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Fixes: ee9f8fce99http://lkml.kernel.org/r/6bada6b9eac86017e16bd79e1e77877935cb50bb.1508516398.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-23 13:30:36 +02:00
Borislav Petkov
bfc1168de9
x86/cpu/AMD: Apply the Erratum 688 fix when the BIOS doesn't
...
Some F14h machines have an erratum which, "under a highly specific
and detailed set of internal timing conditions" can lead to skipping
instructions and RIP corruption.
Add the fix for those machines when their BIOS doesn't apply it or
there simply isn't BIOS update for them.
Tested-by: <mirh@protonmail.ch >
Signed-off-by: Borislav Petkov <bp@suse.de >
Cc: <stable@vger.kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Yazen Ghannam <Yazen.Ghannam@amd.com >
Link: http://lkml.kernel.org/r/20171022104731.28249-1-bp@alien8.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197285
[ Added pr_info() that we activated the workaround. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-22 13:06:02 +02:00
Reinette Chatre
87943db7df
x86/intel_rdt: Fix potential deadlock during resctrl mount
...
Sai reported a warning during some MBA tests:
[ 236.755559] ======================================================
[ 236.762443] WARNING: possible circular locking dependency detected
[ 236.769328] 4.14.0-rc4-yocto-standard #8 Not tainted
[ 236.774857] ------------------------------------------------------
[ 236.781738] mount/10091 is trying to acquire lock:
[ 236.787071] (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8117f892>] static_key_enable+0x12/0x30
[ 236.797058]
but task is already holding lock:
[ 236.803552] (&type->s_umount_key#37/1){+.+.}, at: [<ffffffff81208b2f>] sget_userns+0x32f/0x520
[ 236.813247]
which lock already depends on the new lock.
[ 236.822353]
the existing dependency chain (in reverse order) is:
[ 236.830686]
-> #4 (&type->s_umount_key#37/1){+.+.}:
[ 236.837756] __lock_acquire+0x1100/0x11a0
[ 236.842799] lock_acquire+0xdf/0x1d0
[ 236.847363] down_write_nested+0x46/0x80
[ 236.852310] sget_userns+0x32f/0x520
[ 236.856873] kernfs_mount_ns+0x7e/0x1f0
[ 236.861728] rdt_mount+0x30c/0x440
[ 236.866096] mount_fs+0x38/0x150
[ 236.870262] vfs_kern_mount+0x67/0x150
[ 236.875015] do_mount+0x1df/0xd50
[ 236.879286] SyS_mount+0x95/0xe0
[ 236.883464] entry_SYSCALL_64_fastpath+0x18/0xad
[ 236.889183]
-> #3 (rdtgroup_mutex){+.+.}:
[ 236.895292] __lock_acquire+0x1100/0x11a0
[ 236.900337] lock_acquire+0xdf/0x1d0
[ 236.904899] __mutex_lock+0x80/0x8f0
[ 236.909459] mutex_lock_nested+0x1b/0x20
[ 236.914407] intel_rdt_online_cpu+0x3b/0x4a0
[ 236.919745] cpuhp_invoke_callback+0xce/0xb80
[ 236.925177] cpuhp_thread_fun+0x1c5/0x230
[ 236.930222] smpboot_thread_fn+0x11a/0x1e0
[ 236.935362] kthread+0x152/0x190
[ 236.939536] ret_from_fork+0x27/0x40
[ 236.944097]
-> #2 (cpuhp_state-up){+.+.}:
[ 236.950199] __lock_acquire+0x1100/0x11a0
[ 236.955241] lock_acquire+0xdf/0x1d0
[ 236.959800] cpuhp_issue_call+0x12e/0x1c0
[ 236.964845] __cpuhp_setup_state_cpuslocked+0x13b/0x2f0
[ 236.971242] __cpuhp_setup_state+0xa7/0x120
[ 236.976483] page_writeback_init+0x43/0x67
[ 236.981623] pagecache_init+0x38/0x3b
[ 236.986281] start_kernel+0x3c6/0x41a
[ 236.990931] x86_64_start_reservations+0x2a/0x2c
[ 236.996650] x86_64_start_kernel+0x72/0x75
[ 237.001793] verify_cpu+0x0/0xfb
[ 237.005966]
-> #1 (cpuhp_state_mutex){+.+.}:
[ 237.012364] __lock_acquire+0x1100/0x11a0
[ 237.017408] lock_acquire+0xdf/0x1d0
[ 237.021969] __mutex_lock+0x80/0x8f0
[ 237.026527] mutex_lock_nested+0x1b/0x20
[ 237.031475] __cpuhp_setup_state_cpuslocked+0x54/0x2f0
[ 237.037777] __cpuhp_setup_state+0xa7/0x120
[ 237.043013] page_alloc_init+0x28/0x30
[ 237.047769] start_kernel+0x148/0x41a
[ 237.052425] x86_64_start_reservations+0x2a/0x2c
[ 237.058145] x86_64_start_kernel+0x72/0x75
[ 237.063284] verify_cpu+0x0/0xfb
[ 237.067456]
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
[ 237.074436] check_prev_add+0x401/0x800
[ 237.079286] __lock_acquire+0x1100/0x11a0
[ 237.084330] lock_acquire+0xdf/0x1d0
[ 237.088890] cpus_read_lock+0x42/0x90
[ 237.093548] static_key_enable+0x12/0x30
[ 237.098496] rdt_mount+0x406/0x440
[ 237.102862] mount_fs+0x38/0x150
[ 237.107035] vfs_kern_mount+0x67/0x150
[ 237.111787] do_mount+0x1df/0xd50
[ 237.116058] SyS_mount+0x95/0xe0
[ 237.120233] entry_SYSCALL_64_fastpath+0x18/0xad
[ 237.125952]
other info that might help us debug this:
[ 237.134867] Chain exists of:
cpu_hotplug_lock.rw_sem --> rdtgroup_mutex --> &type->s_umount_key#37/1
[ 237.148425] Possible unsafe locking scenario:
[ 237.155015] CPU0 CPU1
[ 237.160057] ---- ----
[ 237.165100] lock(&type->s_umount_key#37/1);
[ 237.169952] lock(rdtgroup_mutex);
[ 237.176641]
lock(&type->s_umount_key#37/1);
[ 237.184287] lock(cpu_hotplug_lock.rw_sem);
[ 237.189041]
*** DEADLOCK ***
When the resctrl filesystem is mounted the locks must be acquired in the
same order as was done when the cpus came online:
cpu_hotplug_lock before rdtgroup_mutex.
This also requires to switch the static_branch_enable() calls to the
_cpulocked variant because now cpu hotplug lock is held already.
[ tglx: Switched to cpus_read_[un]lock ]
Reported-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com >
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com >
Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com >
Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com >
Cc: fenghua.yu@intel.com
Cc: tony.luck@intel.com
Link: https://lkml.kernel.org/r/9c41b91bc2f47d9e95b62b213ecdb45623c47a9f.1508490116.git.reinette.chatre@intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
2017-10-21 17:12:22 +02:00
Reinette Chatre
36b6f9fcb8
x86/intel_rdt: Fix potential deadlock during resctrl unmount
...
Lockdep warns about a potential deadlock:
[ 66.782842] ======================================================
[ 66.782888] WARNING: possible circular locking dependency detected
[ 66.782937] 4.14.0-rc2-test-test+ #48 Not tainted
[ 66.782983] ------------------------------------------------------
[ 66.783052] umount/336 is trying to acquire lock:
[ 66.783117] (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff81032395>] rdt_kill_sb+0x215/0x390
[ 66.783193]
but task is already holding lock:
[ 66.783244] (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390
[ 66.783305]
which lock already depends on the new lock.
[ 66.783364]
the existing dependency chain (in reverse order) is:
[ 66.783419]
-> #3 (rdtgroup_mutex){+.+.}:
[ 66.783467] __lock_acquire+0x1293/0x13f0
[ 66.783509] lock_acquire+0xaf/0x220
[ 66.783543] __mutex_lock+0x71/0x9b0
[ 66.783575] mutex_lock_nested+0x1b/0x20
[ 66.783610] intel_rdt_online_cpu+0x3b/0x430
[ 66.783649] cpuhp_invoke_callback+0xab/0x8e0
[ 66.783687] cpuhp_thread_fun+0x7a/0x150
[ 66.783722] smpboot_thread_fn+0x1cc/0x270
[ 66.783764] kthread+0x16e/0x190
[ 66.783794] ret_from_fork+0x27/0x40
[ 66.783825]
-> #2 (cpuhp_state){+.+.}:
[ 66.783870] __lock_acquire+0x1293/0x13f0
[ 66.783906] lock_acquire+0xaf/0x220
[ 66.783938] cpuhp_issue_call+0x102/0x170
[ 66.783974] __cpuhp_setup_state_cpuslocked+0x154/0x2a0
[ 66.784023] __cpuhp_setup_state+0xc7/0x170
[ 66.784061] page_writeback_init+0x43/0x67
[ 66.784097] pagecache_init+0x43/0x4a
[ 66.784131] start_kernel+0x3ad/0x3f7
[ 66.784165] x86_64_start_reservations+0x2a/0x2c
[ 66.784204] x86_64_start_kernel+0x72/0x75
[ 66.784241] verify_cpu+0x0/0xfb
[ 66.784270]
-> #1 (cpuhp_state_mutex){+.+.}:
[ 66.784319] __lock_acquire+0x1293/0x13f0
[ 66.784355] lock_acquire+0xaf/0x220
[ 66.784387] __mutex_lock+0x71/0x9b0
[ 66.784419] mutex_lock_nested+0x1b/0x20
[ 66.784454] __cpuhp_setup_state_cpuslocked+0x52/0x2a0
[ 66.784497] __cpuhp_setup_state+0xc7/0x170
[ 66.784535] page_alloc_init+0x28/0x30
[ 66.784569] start_kernel+0x148/0x3f7
[ 66.784602] x86_64_start_reservations+0x2a/0x2c
[ 66.784642] x86_64_start_kernel+0x72/0x75
[ 66.784678] verify_cpu+0x0/0xfb
[ 66.784707]
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
[ 66.784759] check_prev_add+0x32f/0x6e0
[ 66.784794] __lock_acquire+0x1293/0x13f0
[ 66.784830] lock_acquire+0xaf/0x220
[ 66.784863] cpus_read_lock+0x3d/0xb0
[ 66.784896] rdt_kill_sb+0x215/0x390
[ 66.784930] deactivate_locked_super+0x3e/0x70
[ 66.784968] deactivate_super+0x40/0x60
[ 66.785003] cleanup_mnt+0x3f/0x80
[ 66.785034] __cleanup_mnt+0x12/0x20
[ 66.785070] task_work_run+0x8b/0xc0
[ 66.785103] exit_to_usermode_loop+0x94/0xa0
[ 66.786804] syscall_return_slowpath+0xe8/0x150
[ 66.788502] entry_SYSCALL_64_fastpath+0xab/0xad
[ 66.790194]
other info that might help us debug this:
[ 66.795139] Chain exists of:
cpu_hotplug_lock.rw_sem --> cpuhp_state --> rdtgroup_mutex
[ 66.800035] Possible unsafe locking scenario:
[ 66.803267] CPU0 CPU1
[ 66.804867] ---- ----
[ 66.806443] lock(rdtgroup_mutex);
[ 66.808002] lock(cpuhp_state);
[ 66.809565] lock(rdtgroup_mutex);
[ 66.811110] lock(cpu_hotplug_lock.rw_sem);
[ 66.812608]
*** DEADLOCK ***
[ 66.816983] 2 locks held by umount/336:
[ 66.818418] #0 : (&type->s_umount_key#35){+.+.}, at: [<ffffffff81229738>] deactivate_super+0x38/0x60
[ 66.819922] #1 : (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390
When the resctrl filesystem is unmounted the locks should be obtain in the
locks in the same order as was done when the cpus came online:
cpu_hotplug_lock before rdtgroup_mutex.
This also requires to switch the static_branch_disable() calls to the
_cpulocked variant because now cpu hotplug lock is held already.
[ tglx: Switched to cpus_read_[un]lock ]
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com >
Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com >
Acked-by: Fenghua Yu <fenghua.yu@intel.com >
Acked-by: Tony Luck <tony.luck@intel.com >
Link: https://lkml.kernel.org/r/cc292e76be073f7260604651711c47b09fd0dc81.1508490116.git.reinette.chatre@intel.com
2017-10-21 17:12:21 +02:00
Reinette Chatre
95953034fb
x86/intel_rdt: Initialize bitmask of shareable resource if CDP enabled
...
The platform informs via CPUID.(EAX=0x10, ECX=res#):EBX[31:0] (valid res#
are only 1 for L3 and 2 for L2) which unit of the allocation may be used by
other entities in the platform. This information is valid whether CDP (Code
and Data Prioritization) is enabled or not.
Ensure that the bitmask of shareable resource is initialized when CDP is
enabled.
Fixes: 0dd2d7494creinette.chatre@intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Acked-by: Fenghua Yu <fenghua.yu@intel.com >
Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com >
Acked-by: Tony Luck <tony.luck@intel.com >
Link: https://lkml.kernel.org/r/815747bddc820ca221a8924edaf4d1a7324547e4.1508490116.git.reinette.chatre@intel.com
2017-10-21 17:12:21 +02:00
Kirill A. Shutemov
4375c29985
x86/xen: Provide pre-built page tables only for CONFIG_XEN_PV=y and CONFIG_XEN_PVH=y
...
Looks like we only need pre-built page tables in the CONFIG_XEN_PV=y and
CONFIG_XEN_PVH=y cases.
Let's not provide them for other configurations.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com >
Reviewed-by: Juergen Gross <jgross@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Andy Lutomirski <luto@amacapital.net >
Cc: Borislav Petkov <bp@suse.de >
Cc: Cyrill Gorcunov <gorcunov@openvz.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170929140821.37654-5-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-20 13:07:10 +02:00
Andrey Ryabinin
12a8cc7fcf
x86/kasan: Use the same shadow offset for 4- and 5-level paging
...
We are going to support boot-time switching between 4- and 5-level
paging. For KASAN it means we cannot have different KASAN_SHADOW_OFFSET
for different paging modes: the constant is passed to gcc to generate
code and cannot be changed at runtime.
This patch changes KASAN code to use 0xdffffc0000000000 as shadow offset
for both 4- and 5-level paging.
For 5-level paging it means that shadow memory region is not aligned to
PGD boundary anymore and we have to handle unaligned parts of the region
properly.
In addition, we have to exclude paravirt code from KASAN instrumentation
as we now use set_pgd() before KASAN is fully ready.
[kirill.shutemov@linux.intel.com: clenaup, changelog message]
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@suse.de>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170929140821.37654-4-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-20 13:07:09 +02:00
Ingo Molnar
ca4b9c3b74
Merge branch 'perf/urgent' into perf/core, to pick up fixes
...
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-20 11:02:05 +02:00
Dave Hansen
da20ab3518
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
...
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com >
Reviewed-by: Andy Lutomirski <luto@kernel.org >
Reviewed-by: Brian Gerst <brgerst@gmail.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-20 10:37:33 +02:00
Thomas Gleixner
57b8b1a185
x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()
...
do_clear_cpu_cap() allocates a bitmap to keep track of disabled feature
dependencies. That bitmap is sized NCAPINTS * BITS_PER_INIT. The possible
'features' which can be handed in are larger than this, because after the
capabilities the bug 'feature' bits occupy another 32bit. Not really
obvious...
So clearing any of the misfeature bits, as 32bit does for the F00F bug,
accesses that bitmap out of bounds thereby corrupting the stack.
Size the bitmap proper and add a sanity check to catch accidental out of
bound access.
Fixes: 0b00de857axiaolong.ye@intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Andi Kleen <ak@linux.intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Link: https://lkml.kernel.org/r/20171018022023.GA12058@yexl-desktop
2017-10-18 20:03:34 +02:00
Thomas Gleixner
c201c91799
x86/vector/msi: Select CONFIG_GENERIC_IRQ_RESERVATION_MODE
...
Select CONFIG_GENERIC_IRQ_RESERVATION_MODE so PCI/MSI domains get the
MSI_FLAG_MUST_REACTIVATE flag set in pci_msi_create_irq_domain().
Remove the explicit setters of this flag in the apic/msi code as they are
not longer required.
Fixes: 4900be8360decui@microsoft.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Josh Poulson <jopoulso@microsoft.com >
Cc: Mihai Costache <v-micos@microsoft.com >
Cc: Stephen Hemminger <sthemmin@microsoft.com >
Cc: Marc Zyngier <marc.zyngier@arm.com >
Cc: linux-pci@vger.kernel.org
Cc: Haiyang Zhang <haiyangz@microsoft.com >
Cc: Simon Xiao <sixiao@microsoft.com >
Cc: Saeed Mahameed <saeedm@mellanox.com >
Cc: Jork Loeser <Jork.Loeser@microsoft.com >
Cc: Bjorn Helgaas <bhelgaas@google.com >
Cc: devel@linuxdriverproject.org
Cc: KY Srinivasan <kys@microsoft.com >
Link: https://lkml.kernel.org/r/20171017075600.527569354@linutronix.de
2017-10-18 15:38:31 +02:00
Borislav Petkov
723f2828a9
x86/microcode/intel: Disable late loading on model 79
...
Blacklist Broadwell X model 79 for late loading due to an erratum.
Signed-off-by: Borislav Petkov <bp@suse.de >
Acked-by: Tony Luck <tony.luck@intel.com >
Cc: <stable@vger.kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-18 15:20:20 +02:00
Kees Cook
376f3bcebd
x86/platform/UV: Convert timers to use timer_setup()
...
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Signed-off-by: Kees Cook <keescook@chromium.org >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Dimitri Sivanich <sivanich@hpe.com >
Cc: Russ Anderson <rja@hpe.com >
Cc: Mike Travis <mike.travis@hpe.com >
Link: https://lkml.kernel.org/r/20171016232231.GA100493@beast
2017-10-17 17:40:06 +02:00
Andi Kleen
73e3a7d2a7
x86/fpu: Remove the explicit clearing of XSAVE dependent features
...
Clearing a CPU feature with setup_clear_cpu_cap() clears all features
which depend on it. Expressing feature dependencies in one place is
easier to maintain than keeping functions like
fpu__xstate_clear_all_cpu_caps() up to date.
The features which depend on XSAVE have their dependency expressed in the
dependency table, so its sufficient to clear X86_FEATURE_XSAVE.
Remove the explicit clearing of XSAVE dependent features.
Signed-off-by: Andi Kleen <ak@linux.intel.com >
Reviewed-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Link: http://lkml.kernel.org/r/20171013215645.23166-6-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-17 17:14:57 +02:00
Andi Kleen
ccb18db2ab
x86/fpu: Make XSAVE check the base CPUID features before enabling
...
Before enabling XSAVE, not only check the XSAVE specific CPUID bits,
but also the base CPUID features of the respective XSAVE feature.
This allows to disable individual XSAVE states using the existing
clearcpuid= option, which can be useful for performance testing
and debugging, and also in general avoids inconsistencies.
Signed-off-by: Andi Kleen <ak@linux.intel.com >
Reviewed-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Link: http://lkml.kernel.org/r/20171013215645.23166-5-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-17 17:14:57 +02:00
Andi Kleen
0c2a3913d6
x86/fpu: Parse clearcpuid= as early XSAVE argument
...
With a followon patch we want to make clearcpuid affect the XSAVE
configuration. But xsave is currently initialized before arguments
are parsed. Move the clearcpuid= parsing into the special
early xsave argument parsing code.
Since clearcpuid= contains a = we need to keep the old __setup
around as a dummy, otherwise it would end up as a environment
variable in init's environment.
Signed-off-by: Andi Kleen <ak@linux.intel.com >
Reviewed-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Link: http://lkml.kernel.org/r/20171013215645.23166-4-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-17 17:14:57 +02:00
Andi Kleen
0b00de857a
x86/cpuid: Add generic table for CPUID dependencies
...
Some CPUID features depend on other features. Currently it's
possible to to clear dependent features, but not clear the base features,
which can cause various interesting problems.
This patch implements a generic table to describe dependencies
between CPUID features, to be used by all code that clears
CPUID.
Some subsystems (like XSAVE) had an own implementation of this,
but it's better to do it all in a single place for everyone.
Then clear_cpu_cap and setup_clear_cpu_cap always look up
this table and clear all dependencies too.
This is intended to be a practical table: only for features
that make sense to clear. If someone for example clears FPU,
or other features that are essentially part of the required
base feature set, not much is going to work. Handling
that is right now out of scope. We're only handling
features which can be usefully cleared.
Signed-off-by: Andi Kleen <ak@linux.intel.com >
Reviewed-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Jonathan McDowell <noodles@earth.li >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Link: http://lkml.kernel.org/r/20171013215645.23166-3-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-17 17:14:57 +02:00
Thomas Gleixner
0696d059f2
x86/vector: Use correct per cpu variable in free_moved_vector()
...
free_moved_vector() accesses the per cpu vector array with this_cpu_write()
to clear the vector. The function has two call sites:
1) The vector cleanup IPI
2) The force_complete_move() code path
For #1 this_cpu_write() is correct as it runs on the CPU on which the
vector needs to be freed.
For #2 this_cpu_write() is wrong because the function is called from an
outgoing CPU which is not necessarily the CPU on which the previous vector
needs to be freed. As a result it sets the vector on the outgoing CPU to
NULL, which is pointless as that CPU does not handle interrupts
anymore. What's worse is that it leaves the vector on the previous target
CPU in place which later on triggers the BUG_ON(vector) in the vector
allocation code when the vector gets reused. That's possible because the
bitmap allocator entry of that CPU is freed correctly.
Always use the CPU to which the vector was associated and clear the vector
entry on that CPU. Fixup the tracepoint as well so it tracks on which CPU
the vector gets removed.
Fixes: 69cde0004apetri.latvala@intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Juergen Gross <jgross@suse.com >
Cc: Tony Luck <tony.luck@intel.com >
Cc: Len Brown <lenb@kernel.org >
Cc: Marc Zyngier <marc.zyngier@arm.com >
Cc: Joerg Roedel <joro@8bytes.org >
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: Christoph Hellwig <hch@lst.de >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Rui Zhang <rui.zhang@intel.com >
Cc: Borislav Petkov <bp@alien8.de >
Cc: Paolo Bonzini <pbonzini@redhat.com >
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com >
Cc: "K. Y. Srinivasan" <kys@microsoft.com >
Cc: Arjan van de Ven <arjan@linux.intel.com >
Cc: Alok Kataria <akataria@vmware.com >
Cc: Dan Williams <dan.j.williams@intel.com >
Cc: Yu Chen <yu.c.chen@intel.com >
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710161614430.1973@nanos
2017-10-17 16:45:09 +02:00
mike.travis@hpe.com
97d21003df
x86/platform/UV: Add check of TSC state set by UV BIOS
...
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC
as the kernel will not be able to set an accurate TSC sync either.
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Reviewed-by: Russ Anderson <russ.anderson@hpe.com >
Reviewed-by: Andrew Banman <andrew.abanman@hpe.com >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171012163202.406294490@stormcage.americas.sgi.com
2017-10-16 22:50:37 +02:00
mike.travis@hpe.com
6c66350d0a
x86/tsc: Provide a means to disable TSC ART
...
On systems where multiple chassis are reset asynchronously, and thus
the TSC counters are started asynchronously, the offset needed to
convert to TSC to ART would be different. Disable ART in that case
and rely on the TSC counters to supply the accurate time.
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Cc: Russ Anderson <russ.anderson@hpe.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171012163202.289397994@stormcage.americas.sgi.com
2017-10-16 22:50:37 +02:00
mike.travis@hpe.com
41e7864ab5
x86/tsc: Drastically reduce the number of firmware bug warnings
...
Prior to the TSC ADJUST MSR being available, the method to set TSC's in
sync with each other naturally caused a small skew between cpu threads.
This was NOT a firmware bug at the time so introducing a whole avalanche
of alarming warning messages might cause unnecessary concern and customer
complaints. (Example: >3000 msgs in a 32 socket Skylake system.)
Simply report the warning condition, if possible do the necessary fixes,
and move on.
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Reviewed-by: Russ Anderson <russ.anderson@hpe.com >
Reviewed-by: Peter Zijlstra <peterz@infradead.org >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171012163202.175062400@stormcage.americas.sgi.com
2017-10-16 22:50:36 +02:00
mike.travis@hpe.com
9514ececa5
x86/tsc: Skip TSC test and error messages if already unstable
...
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Reviewed-by: Russ Anderson <russ.anderson@hpe.com >
Reviewed-by: Peter Zijlstra <peterz@infradead.org >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171012163202.060777495@stormcage.americas.sgi.com
2017-10-16 22:50:36 +02:00
mike.travis@hpe.com
341102c3ef
x86/tsc: Add option that TSC on Socket 0 being non-zero is valid
...
Add a flag to indicate and process that TSC counters are on chassis
that reset at different times during system startup. Therefore which
TSC ADJUST values should be zero is not predictable.
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Reviewed-by: Russ Anderson <russ.anderson@hpe.com >
Reviewed-by: Andrew Banman <andrew.abanman@hpe.com >
Reviewed-by: Peter Zijlstra <peterz@infradead.org >
Cc: Prarit Bhargava <prarit@redhat.com >
Cc: Andrew Banman <andrew.banman@hpe.com >
Cc: Bin Gao <bin.gao@linux.intel.com >
Link: https://lkml.kernel.org/r/20171012163201.944370012@stormcage.americas.sgi.com
2017-10-16 22:50:36 +02:00
Thomas Gleixner
9c48c0965b
x86/idt: Initialize early IDT before cr4_init_shadow()
...
Moving the early IDT setup out of assembly code breaks the boot on first
generation 486 systems.
The reason is that the call of idt_setup_early_handler, which sets up the
early handlers was added after the call to cr4_init_shadow().
cr4_init_shadow() tries to read CR4 which is not available on those
systems. The accessor function uses a extable fixup to handle the resulting
fault. As the IDT is not set up yet, the cr4 read exception causes an
instantaneous reboot for obvious reasons.
Call idt_setup_early_handler() before cr4_init_shadow() so IDT is set up
before the first exception hits.
Fixes: 87e81786b1whiteheadm@acm.org >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Andy Lutomirski <luto@kernel.org >
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710161210290.1973@nanos
2017-10-16 20:47:37 +02:00
Colin Ian King
e6fc454b77
x86/cpu/intel_cacheinfo: Remove redundant assignment to 'this_leaf'
...
The 'this_leaf' variable is assigned a value that is never
read and it is updated a little later with a newer value,
hence we can remove the redundant assignment.
Cleans up the following Clang warning:
Value stored to 'this_leaf' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com >
Reviewed-by: Borislav Petkov <bp@suse.de >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: kernel-janitors@vger.kernel.org
Link: http://lkml.kernel.org/r/20171015160203.12332-1-colin.king@canonical.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-16 09:25:18 +02:00
Linus Torvalds
e7a36a6ec9
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
...
Pull x86 fixes from Ingo Molnar:
"A landry list of fixes:
- fix reboot breakage on some PCID-enabled system
- fix crashes/hangs on some PCID-enabled systems
- fix microcode loading on certain older CPUs
- various unwinder fixes
- extend an APIC quirk to more hardware systems and disable APIC
related warning on virtualized systems
- various Hyper-V fixes
- a macro definition robustness fix
- remove jprobes IRQ disabling
- various mem-encryption fixes"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode: Do the family check first
x86/mm: Flush more aggressively in lazy TLB mode
x86/apic: Update TSC_DEADLINE quirk with additional SKX stepping
x86/apic: Silence "FW_BUG TSC_DEADLINE disabled due to Errata" on hypervisors
x86/mm: Disable various instrumentations of mm/mem_encrypt.c and mm/tlb.c
x86/hyperv: Fix hypercalls with extended CPU ranges for TLB flushing
x86/hyperv: Don't use percpu areas for pcpu_flush/pcpu_flush_ex structures
x86/hyperv: Clear vCPU banks between calls to avoid flushing unneeded vCPUs
x86/unwind: Disable unwinder warnings on 32-bit
x86/unwind: Align stack pointer in unwinder dump
x86/unwind: Use MSB for frame pointer encoding on 32-bit
x86/unwind: Fix dereference of untrusted pointer
x86/alternatives: Fix alt_max_short macro to really be a max()
x86/mm/64: Fix reboot interaction with CR4.PCIDE
kprobes/x86: Remove IRQ disabling from jprobe handlers
kprobes/x86: Set up frame pointer in kprobe trampoline
2017-10-14 15:26:38 -04:00
Linus Torvalds
7b764cedcb
Merge branch 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
...
Pull RAS fixes from Ingo Molnar:
"A boot parameter fix, plus a header export fix"
* 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Hide mca_cfg
RAS/CEC: Use the right length for "cec_disable"
2017-10-14 15:19:11 -04:00
Borislav Petkov
1f161f67a2
x86/microcode: Do the family check first
...
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.
However, we do the family check *after* the other checks whether the
loader has been disabled on the command line or whether we're running in
a guest.
So move the family checks first in order to exit early if we're being
loaded on an unsupported family.
Reported-and-tested-by: Sven Glodowski <glodi1@arcor.de >
Signed-off-by: Borislav Petkov <bp@suse.de >
Cc: <stable@vger.kernel.org > # 4.11..
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396
Link: http://lkml.kernel.org/r/20171012112316.977-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-14 12:55:40 +02:00
Josh Poimboeuf
11af847446
x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'
...
Rename the unwinder config options from:
CONFIG_ORC_UNWINDER
CONFIG_FRAME_POINTER_UNWINDER
CONFIG_GUESS_UNWINDER
to:
CONFIG_UNWINDER_ORC
CONFIG_UNWINDER_FRAME_POINTER
CONFIG_UNWINDER_GUESS
... in order to give them a more logical config namespace.
Suggested-by: Ingo Molnar <mingo@kernel.org >
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org >
2017-10-14 10:12:12 +02:00
Len Brown
616dd5872e
x86/apic: Update TSC_DEADLINE quirk with additional SKX stepping
...
SKX stepping-3 fixed the TSC_DEADLINE issue in a different ucode
version number than stepping-4. Linux needs to know this stepping-3
specific version number to also enable the TSC_DEADLINE on stepping-3.
The steppings and ucode versions are documented in the SKX BIOS update:
https://downloadmirror.intel.com/26978/eng/ReleaseNotes_R00.01.0004.txt
Signed-off-by: Len Brown <len.brown@intel.com >
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Cc: peterz@infradead.org
Link: https://lkml.kernel.org/r/60f2bbf7cf617e212b522e663f84225bfebc50e5.1507756305.git.len.brown@intel.com
2017-10-12 17:10:11 +02:00
