linux-toradex.git/arch, branch v4.4.156

s390/lib: use expoline for all bcr instructions

2018-09-15T07:40:42+00:00

commit 5eda25b10297684c1f46a14199ec00210f3c346e upstream.

The memove, memset, memcpy, __memset16, __memset32 and __memset64
function have an additional indirect return branch in form of a
"bzr" instruction. These need to use expolines as well.

Cc:  # v4.17+
Fixes: 97489e0663 ("s390/lib: use expoline for indirect branches")
Reviewed-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3: Add missing barrier to 32bit version of gic_read_iar()

2018-09-15T07:40:41+00:00

commit 8f318526a292c5e7cebb82f3f766b83c22343293 upstream.

Commit 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is
visible on redestributor") fixed the missing barrier on arm64, but
forgot to update the 32bit counterpart, which has the same requirements.
Let's fix it.

Fixes: 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor")
Signed-off-by: Marc Zyngier 
Signed-off-by: Hanjun Guo 
Signed-off-by: Greg Kroah-Hartman

Revert "ARM: imx_v6_v7_defconfig: Select ULPI support"

2018-09-15T07:40:40+00:00

This reverts commit 0d0af17ae83d6feb29d676c72423461419df5110.

This commit causes reboot to fail on imx6 wandboard, so let's
revert it.

Cc:  #4.4
Reported-by: Rasmus Villemoes 
Signed-off-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear

2018-09-15T07:40:40+00:00

commit b2d7a075a1ccef2fb321d595802190c8e9b39004 upstream.

Using only 32-bit writes for the pte will result in an intermediate
L1TF vulnerable PTE. When running as a Xen PV guest this will at once
switch the guest to shadow mode resulting in a loss of performance.

Use arch_atomic64_xchg() instead which will perform the requested
operation atomically with all 64 bits.

Some performance considerations according to:

https://software.intel.com/sites/default/files/managed/ad/dc/Intel-Xeon-Scalable-Processor-throughput-latency.pdf

The main number should be the latency, as there is no tight loop around
native_ptep_get_and_clear().

"lock cmpxchg8b" has a latency of 20 cycles, while "lock xchg" (with a
memory operand) isn't mentioned in that document. "lock xadd" (with xadd
having 3 cycles less latency than xchg) has a latency of 11, so we can
assume a latency of 14 for "lock xchg".

Signed-off-by: Juergen Gross 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Jan Beulich 
Tested-by: Jason Andryuk 
Signed-off-by: Boris Ostrovsky 
[ Atomic operations gained an arch_ prefix in 8bf705d13039
("locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h") so
s/arch_atomic64_xchg/atomic64_xchg/ for backport.]
Signed-off-by: Jason Andryuk 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX.

2018-09-15T07:40:39+00:00

[ Upstream commit 74e96bf44f430cf7a01de19ba6cf49b361cdfd6e ]

The global mce data buffer that used to copy rtas error log is of 2048
(RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read
extended_log_length from rtas error log header, then use max of
extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied.
Ideally the platform (phyp) will never send extended error log with
size > 2048. But if that happens, then we have a risk of buffer overrun
and corruption. Fix this by using min_t instead.

Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data")
Reported-by: Michal Suchanek 
Signed-off-by: Mahesh Salgaonkar 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix size calculation using resource_size()

2018-09-15T07:40:39+00:00

[ Upstream commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 ]

The problem is the the calculation should be "end - start + 1" but the
plus one is missing in this calculation.

Fixes: 8626816e905e ("powerpc: add support for MPIC message register API")
Signed-off-by: Dan Carpenter 
Reviewed-by: Tyrel Datwyler 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

x86/speculation/l1tf: Fix up pte->pfn conversion for PAE

2018-09-15T07:40:37+00:00

commit e14d7dfb41f5807a0c1c26a13f2b8ef16af24935 upstream.

Jan has noticed that pte_pfn and co. resp. pfn_pte are incorrect for
CONFIG_PAE because phys_addr_t is wider than unsigned long and so the
pte_val reps. shift left would get truncated. Fix this up by using proper
types.

[Just one chunk, again, needed here.  Thanks to Ben and Guenter for
finding and fixing this. - gregkh]

Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation")
Reported-by: Jan Beulich 
Signed-off-by: Michal Hocko 
Signed-off-by: Thomas Gleixner 
Acked-by: Vlastimil Babka 
Cc: Guenter Roeck 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

x86/io: add interface to reserve io memtype for a resource range. (v1.1)

2018-09-09T18:04:36+00:00

commit 8ef4227615e158faa4ee85a1d6466782f7e22f2f upstream.

A recent change to the mm code in:
87744ab3832b mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT + add some comments in io.h

Cc: Toshi Kani 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Andy Lutomirski 
Cc: Denys Vlasenko 
Cc: Brian Gerst 
Cc: x86@kernel.org
Cc: mcgrof@suse.com
Cc: Dan Williams 
Acked-by: Ingo Molnar 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Dave Airlie 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

sys: don't hold uts_sem while accessing userspace memory

2018-09-09T18:04:35+00:00

commit 42a0cc3478584d4d63f68f2f5af021ddbea771fa upstream.

Holding uts_sem as a writer while accessing userspace memory allows a
namespace admin to stall all processes that attempt to take uts_sem.
Instead, move data through stack buffers and don't access userspace memory
while uts_sem is held.

Cc: stable@vger.kernel.org
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jann Horn 
Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman

osf_getdomainname(): use copy_to_user()

2018-09-09T18:04:35+00:00

commit 9ba3eb5103cf56f0daaf07de4507df76e7813ed7 upstream.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman