linux-stable.git/arch, branch v4.4.161

ARC: clone syscall to setp r25 as thread pointer

2018-10-13T07:11:34+00:00

commit c58a584f05e35d1d4342923cd7aac07d9c3d3d16 upstream.

Per ARC TLS ABI, r25 is designated TP (thread pointer register).
However so far kernel didn't do any special treatment, like setting up
usermode r25, even for CLONE_SETTLS. We instead relied on libc runtime
to do this, in say clone libc wrapper [1]. This was deliberate to keep
kernel ABI agnostic (userspace could potentially change TP, specially
for different ARC ISA say ARCompact vs. ARCv2 with different spare
registers etc)

However userspace setting up r25, after clone syscall opens a race, if
child is not scheduled and gets a signal instead. It starts off in
userspace not in clone but in a signal handler and anything TP sepcific
there such as pthread_self() fails which showed up with uClibc
testsuite nptl/tst-kill6 [2]

Fix this by having kernel populate r25 to TP value. So this locks in
ABI, but it was not going to change anyways, and fwiw is same for both
ARCompact (arc700 core) and ARCvs (HS3x cores)

[1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/clone.S
[2] https://github.com/wbx-github/uclibc-ng-test/blob/master/test/nptl/tst-kill6.c

Fixes: ARC STAR 9001378481
Cc: stable@vger.kernel.org
Reported-by: Nikita Sobolev 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

powerpc/fadump: Return error when fadump registration fails

2018-10-13T07:11:33+00:00

commit 98b8cd7f75643e0a442d7a4c1cef2c9d53b7e92b upstream.

 - log an error message when registration fails and no error code listed
   in the switch is returned
 - translate the hv error code to posix error code and return it from
   fw_register
 - return the posix error code from fw_register to the process writing
   to sysfs
 - return EEXIST on re-registration
 - return success on deregistration when fadump is not registered
 - return ENODEV when no memory is reserved for fadump

Signed-off-by: Michal Suchanek 
Tested-by: Hari Bathini 
[mpe: Use pr_err() to shrink the error print]
Signed-off-by: Michael Ellerman 
Cc: Kleber Sacilotto de Souza 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Fix vDSO syscall fallback asm constraint regression

2018-10-13T07:11:32+00:00

commit 02e425668f5c9deb42787d10001a3b605993ad15 upstream.

When I added the missing memory outputs, I failed to update the
index of the first argument (ebx) on 32-bit builds, which broke the
fallbacks.  Somehow I must have screwed up my testing or gotten
lucky.

Add another test to cover gettimeofday() as well.

Signed-off-by: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Fixes: 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
Link: http://lkml.kernel.org/r/21bd45ab04b6d838278fa5bebfa9163eceffa13c.1538608971.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Fix asm constraints on vDSO syscall fallbacks

2018-10-13T07:11:31+00:00

commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b upstream.

The syscall fallbacks in the vDSO have incorrect asm constraints.
They are not marked as writing to their outputs -- instead, they are
marked as clobbering "memory", which is useless.  In particular, gcc
is smart enough to know that the timespec parameter hasn't escaped,
so a memory clobber doesn't clobber it.  And passing a pointer as an
asm *input* does not tell gcc that the pointed-to value is changed.

Add in the fact that the asm instructions weren't volatile, and gcc
was free to omit them entirely unless their sole output (the return
value) is used.  Which it is (phew!), but that stops happening with
some upcoming patches.

As a trivial example, the following code:

void test_fallback(struct timespec *ts)
{
	vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
}

compiles to:

00000000000000c0 :
  c0:   c3                      retq

To add insult to injury, the RCX and R11 clobbers on 64-bit
builds were missing.

The "memory" clobber is also unnecessary -- no ordering with respect to
other memory operations is needed, but that's going to be fixed in a
separate not-for-stable patch.

Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
Signed-off-by: Andy Lutomirski 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/2c0231690551989d2fafa60ed0e7b5cc8b403908.1538422295.git.luto@kernel.org
Signed-off-by: Greg Kroah-Hartman

arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto"

2018-10-10T06:52:12+00:00

[ Upstream commit 13aceef06adfaf93d52e01e28a8bc8a0ad471d83 ]

All other uses of "asm goto" go through asm_volatile_goto, which avoids
a miscompile when using GCC < 4.8.2. Replace our open-coded "asm goto"
statements with the asm_volatile_goto macro to avoid issues with older
toolchains.

Cc: Catalin Marinas 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Miguel Ojeda 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

hexagon: modify ffs() and fls() to return int

2018-10-10T06:52:12+00:00

[ Upstream commit 5c41aaad409c097cf1ef74f2c649fed994744ef5 ]

Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning.  This is due to hexagon's ffs() being
coded as returning long instead of int.

Fix the printk format warning by changing all of hexagon's ffs() and
fls() functions to return int instead of long.  The variables that
they return are already int instead of long.  This return type
matches the return type in .

../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]

There are no ffs() or fls() allmodconfig build errors after making this
change.

Signed-off-by: Randy Dunlap 
Cc: Richard Kuo 
Cc: linux-hexagon@vger.kernel.org
Cc: Geert Uytterhoeven 
Patch-mainline: linux-kernel @ 07/22/2018, 16:03
Signed-off-by: Richard Kuo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

arch/hexagon: fix kernel/dma.c build warning

2018-10-10T06:52:12+00:00

[ Upstream commit 200f351e27f014fcbf69b544b0b4b72aeaf45fd3 ]

Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.

../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default]
../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'

Signed-off-by: Randy Dunlap 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux-sh@vger.kernel.org
Patch-mainline: linux-kernel @ 07/20/2018, 20:17
[rkuo@codeaurora.org: fixed architecture name]
Signed-off-by: Richard Kuo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: Don't truncate HPTE index in xlate function

2018-10-10T06:52:10+00:00

[ Upstream commit 46dec40fb741f00f1864580130779aeeaf24fb3d ]

This fixes a bug which causes guest virtual addresses to get translated
to guest real addresses incorrectly when the guest is using the HPT MMU
and has more than 256GB of RAM, or more specifically has a HPT larger
than 2GB.  This has showed up in testing as a failure of the host to
emulate doorbell instructions correctly on POWER9 for HPT guests with
more than 256GB of RAM.

The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate()
is stored as an int, and in forming the HPTE address, the index gets
shifted left 4 bits as an int before being signed-extended to 64 bits.
The simple fix is to make the variable a long int, matching the
return type of kvmppc_hv_find_lock_hpte(), which is what calculates
the index.

Fixes: 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests")
Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Sanitize PSTATE.M when being set from userspace

2018-10-10T06:52:09+00:00

commit 2a3f93459d689d990b3ecfbe782fec89b97d3279 upstream.

Not all execution modes are valid for a guest, and some of them
depend on what the HW actually supports. Let's verify that what
userspace provides is compatible with both the VM settings and
the HW capabilities.

Cc: 
Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")
Reviewed-by: Christoffer Dall 
Reviewed-by: Mark Rutland 
Reviewed-by: Dave Martin 
Signed-off-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

arm64: cpufeature: Track 32bit EL0 support

2018-10-10T06:52:09+00:00

commit 042446a31e3803d81c7e618dd80928dc3dce70c5 upstream.

Add cpu_hwcap bit for keeping track of the support for 32bit EL0.

Tested-by: Yury Norov 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman