linux-stable.git/arch, branch linux-4.16.y

x86/intel_rdt: Enable CMT and MBM on new Skylake stepping

2018-06-25T23:54:05+00:00

commit 1d9f3e20a56d33e55748552aeec597f58542f92d upstream.

New stepping of Skylake has fixes for cache occupancy and memory
bandwidth monitoring.

Update the code to enable these by default on newer steppings.

Signed-off-by: Tony Luck 
Signed-off-by: Thomas Gleixner 
Cc: Fenghua Yu 
Cc: stable@vger.kernel.org # v4.14
Cc: Vikas Shivappa 
Link: https://lkml.kernel.org/r/20180608160732.9842-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman

x86/platform/uv: Use apic_ack_irq()

2018-06-25T23:54:04+00:00

commit 839b0f1c4ef674cd929a42304c078afca278581a upstream.

To address the EBUSY fail of interrupt affinity settings in case that the
previous setting has not been cleaned up yet, use the new apic_ack_irq()
function instead of the special uv_ack_apic() implementation which is
merily a wrapper around ack_APIC_irq().

Preparatory change for the real fix

Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
Reported-by: Song Liu 
Signed-off-by: Thomas Gleixner 
Tested-by: Song Liu 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: stable@vger.kernel.org
Cc: Mike Travis 
Cc: Borislav Petkov 
Cc: Tariq Toukan 
Link: https://lkml.kernel.org/r/20180604162224.721691398@linutronix.de
Signed-off-by: Greg Kroah-Hartman

x86/ioapic: Use apic_ack_irq()

2018-06-25T23:54:04+00:00

commit 2b04e46d8d0b9b7ac08ded672e3eab823f01d77a upstream.

To address the EBUSY fail of interrupt affinity settings in case that the
previous setting has not been cleaned up yet, use the new apic_ack_irq()
function instead of directly invoking ack_APIC_irq().

Preparatory change for the real fix

Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
Signed-off-by: Thomas Gleixner 
Tested-by: Song Liu 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: stable@vger.kernel.org
Cc: Mike Travis 
Cc: Borislav Petkov 
Cc: Tariq Toukan 
Link: https://lkml.kernel.org/r/20180604162224.639011135@linutronix.de
Signed-off-by: Greg Kroah-Hartman

x86/apic: Provide apic_ack_irq()

2018-06-25T23:54:03+00:00

commit c0255770ccdc77ef2184d2a0a2e0cde09d2b44a4 upstream.

apic_ack_edge() is explicitely for handling interrupt affinity cleanup when
interrupt remapping is not available or disable.

Remapped interrupts and also some of the platform specific special
interrupts, e.g. UV, invoke ack_APIC_irq() directly.

To address the issue of failing an affinity update with -EBUSY the delayed
affinity mechanism can be reused, but ack_APIC_irq() does not handle
that. Adding this to ack_APIC_irq() is not possible, because that function
is also used for exceptions and directly handled interrupts like IPIs.

Create a new function, which just contains the conditional invocation of
irq_move_irq() and the final ack_APIC_irq().

Reuse the new function in apic_ack_edge().

Preparatory change for the real fix.

Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
Signed-off-by: Thomas Gleixner 
Tested-by: Song Liu 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: stable@vger.kernel.org
Cc: Mike Travis 
Cc: Borislav Petkov 
Cc: Tariq Toukan 
Link: https://lkml.kernel.org/r/20180604162224.471925894@linutronix.de
Signed-off-by: Greg Kroah-Hartman

x86/apic/vector: Prevent hlist corruption and leaks

2018-06-25T23:54:03+00:00

commit 80ae7b1a918e78b0bae88b0c0ad413d3fdced968 upstream.

Several people observed the WARN_ON() in irq_matrix_free() which triggers
when the caller tries to free an vector which is not in the allocation
range. Song provided the trace information which allowed to decode the root
cause.

The rework of the vector allocation mechanism failed to preserve a sanity
check, which prevents setting a new target vector/CPU when the previous
affinity change has not fully completed.

As a result a half finished affinity change can be overwritten, which can
cause the leak of a irq descriptor pointer on the previous target CPU and
double enqueue of the hlist head into the cleanup lists of two or more
CPUs. After one CPU cleaned up its vector the next CPU will invoke the
cleanup handler with vector 0, which triggers the out of range warning in
the matrix allocator.

Prevent this by checking the apic_data of the interrupt whether the
move_in_progress flag is false and the hlist node is not hashed. Return
-EBUSY if not.

This prevents the damage and restores the behaviour before the vector
allocation rework, but due to other changes in that area it also widens the
chance that user space can observe -EBUSY. In theory this should be fine,
but actually not all user space tools handle -EBUSY correctly. Addressing
that is not part of this fix, but will be addressed in follow up patches.

Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
Reported-by: Dmitry Safonov <0x7f454c46@gmail.com>
Reported-by: Tariq Toukan 
Reported-by: Song Liu 
Signed-off-by: Thomas Gleixner 
Tested-by: Song Liu 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Cc: Mike Travis 
Cc: Borislav Petkov 
Link: https://lkml.kernel.org/r/20180604162224.303870257@linutronix.de
Signed-off-by: Greg Kroah-Hartman

x86/vector: Fix the args of vector_alloc tracepoint

2018-06-25T23:54:03+00:00

commit 838d76d63ec4eaeaa12bedfa50f261480f615200 upstream.

The vector_alloc tracepont reversed the reserved and ret aggs, that made
the trace print wrong. Exchange them.

Fixes: 8d1e3dca7de6 ("x86/vector: Add tracepoints for vector management")
Signed-off-by: Dou Liyang 
Signed-off-by: Thomas Gleixner 
Cc: hpa@zytor.com
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180601065031.21872-1-douly.fnst@cn.fujitsu.com
Signed-off-by: Greg Kroah-Hartman

x86/MCE: Fix stack out-of-bounds write in mce-inject.c: Flags_read()

2018-06-25T23:53:59+00:00

commit 985c78d3ff8e9c74450fa2bb08eb55e680d999ca upstream.

Each of the strings that we want to put into the buf[MAX_FLAG_OPT_SIZE]
in flags_read() is two characters long. But the sprintf() adds
a trailing newline and will add a terminating NUL byte. So
MAX_FLAG_OPT_SIZE needs to be 4.

sprintf() calls vsnprintf() and *that* does return:

" * The return value is the number of characters which would
 * be generated for the given input, excluding the trailing
 * '\0', as per ISO C99."

Note the "excluding".

Reported-by: Dmitry Vyukov 
Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20180427163707.ktaiysvbk3yhk4wm@agluck-desk
Signed-off-by: Greg Kroah-Hartman

ARM: fix kill( ,SIGFPE) breakage

2018-06-20T19:01:47+00:00

[ Upstream commit 92d44a42af81e850a038c38278ff4f434b2871df ]

Commit 7771c6645700 ("signal/arm: Document conflicts with SI_USER and
SIGFPE") broke the siginfo structure for userspace triggered signals,
causing the strace testsuite to regress.  Fix this by eliminating
the FPE_FIXME definition (which is at the root of the breakage) and
use FPE_FLTINV instead for the case where the hardware appears to be
reporting nonsense.

Fixes: 7771c6645700 ("signal/arm: Document conflicts with SI_USER and SIGFPE")
Suggested-by: Linus Torvalds 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: replace unnecessary perl with sed and the shell $(( )) operator

2018-06-20T19:01:47+00:00

[ Upstream commit 6cea14f55474ec71f1098228e0ae5dd2a8f22c0a ]

You can build a kernel in a cross compiling environment that doesn't
have perl in the $PATH. Commit 429f7a062e3b broke that for 32 bit
ARM. Fix it.

As reported by Stephen Rothwell, it appears that the symbols can be
either part of the BSS section or absolute symbols depending on the
binutils version.  When they're an absolute symbol, the $(( ))
operator errors out and the build fails.  Fix this as well.

Fixes: 429f7a062e3b ("ARM: decompressor: fix BSS size calculation")
Reported-by: Rob Landley 
Reported-by: Stephen Rothwell 
Acked-by: Rob Landley 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: kexec: fix kdump register saving on panic()

2018-06-20T19:01:47+00:00

[ Upstream commit 2d7b3c64431245c95b05a441669c074da10db943 ]

When a panic() occurs, the kexec code uses smp_send_stop() to stop
the other CPUs, but this results in the CPU register state not being
saved, and gdb is unable to inspect the state of other CPUs.

Commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump
friendly version in panic path") addressed the issue on x86, but
ignored other architectures.  Address the issue on ARM by splitting
out the crash stop implementation to crash_smp_send_stop() and
adding the necessary protection.

Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman