linux-stable.git/arch, branch v5.10.78

riscv: Fix asan-stack clang build

2021-11-02T18:48:25+00:00

commit 54c5639d8f507ebefa814f574cb6f763033a72a5 upstream.

Nathan reported that because KASAN_SHADOW_OFFSET was not defined in
Kconfig, it prevents asan-stack from getting disabled with clang even
when CONFIG_KASAN_STACK is disabled: fix this by defining the
corresponding config.

Reported-by: Nathan Chancellor 
Signed-off-by: Alexandre Ghiti 
Fixes: 8ad8b72721d0 ("riscv: Add KASAN support")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Greg Kroah-Hartman

riscv: fix misalgned trap vector base address

2021-11-02T18:48:25+00:00

commit 64a19591a2938b170aa736443d5d3bf4c51e1388 upstream.

The trap vector marked by label .Lsecondary_park must align on a
4-byte boundary, as the {m,s}tvec is defined to require 4-byte
alignment.

Signed-off-by: Chen Lu <181250012@smail.nju.edu.cn>
Reviewed-by: Anup Patel 
Fixes: e011995e826f ("RISC-V: Move relocate and few other functions out of __init")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: preserve deliverable_mask in __airqs_kick_single_vcpu

2021-11-02T18:48:24+00:00

[ Upstream commit 0e9ff65f455dfd0a8aea5e7843678ab6fe097e21 ]

Changing the deliverable mask in __airqs_kick_single_vcpu() is a bug. If
one idle vcpu can't take the interrupts we want to deliver, we should
look for another vcpu that can, instead of saying that we don't want
to deliver these interrupts by clearing the bits from the
deliverable_mask.

Fixes: 9f30f6216378 ("KVM: s390: add gib_alert_irq_handler()")
Signed-off-by: Halil Pasic 
Reviewed-by: Christian Borntraeger 
Reviewed-by: Michael Mueller 
Reviewed-by: Claudio Imbrenda 
Link: https://lore.kernel.org/r/20211019175401.3757927-3-pasic@linux.ibm.com
Signed-off-by: Christian Borntraeger 
Signed-off-by: Sasha Levin

KVM: s390: clear kicked_mask before sleeping again

2021-11-02T18:48:24+00:00

[ Upstream commit 9b57e9d5010bbed7c0d9d445085840f7025e6f9a ]

The idea behind kicked mask is that we should not re-kick a vcpu that
is already in the "kick" process, i.e. that was kicked and is
is about to be dispatched if certain conditions are met.

The problem with the current implementation is, that it assumes the
kicked vcpu is going to enter SIE shortly. But under certain
circumstances, the vcpu we just kicked will be deemed non-runnable and
will remain in wait state. This can happen, if the interrupt(s) this
vcpu got kicked to deal with got already cleared (because the interrupts
got delivered to another vcpu). In this case kvm_arch_vcpu_runnable()
would return false, and the vcpu would remain in kvm_vcpu_block(),
but this time with its kicked_mask bit set. So next time around we
wouldn't kick the vcpu form __airqs_kick_single_vcpu(), but would assume
that we just kicked it.

Let us make sure the kicked_mask is cleared before we give up on
re-dispatching the vcpu.

Fixes: 9f30f6216378 ("KVM: s390: add gib_alert_irq_handler()")
Reported-by: Matthew Rosato 
Signed-off-by: Halil Pasic 
Reviewed-by: Christian Borntraeger 
Reviewed-by: Michael Mueller 
Reviewed-by: Claudio Imbrenda 
Link: https://lore.kernel.org/r/20211019175401.3757927-2-pasic@linux.ibm.com
Signed-off-by: Christian Borntraeger 
Signed-off-by: Sasha Levin

nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

2021-11-02T18:48:23+00:00

commit 4a089e95b4d6bb625044d47aed0c442a8f7bd093 upstream.

nios2:allmodconfig builds fail with

make[1]: *** No rule to make target 'arch/nios2/boot/dts/""',
	needed by 'arch/nios2/boot/dts/built-in.a'.  Stop.
make: [Makefile:1868: arch/nios2/boot/dts] Error 2 (ignored)

This is seen with compile tests since those enable NIOS2_DTB_SOURCE_BOOL,
which in turn enables NIOS2_DTB_SOURCE. This causes the build error
because the default value for NIOS2_DTB_SOURCE is an empty string.
Disable NIOS2_DTB_SOURCE_BOOL for compile tests to avoid the error.

Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
Signed-off-by: Guenter Roeck 
Reviewed-by: Randy Dunlap 
Signed-off-by: Dinh Nguyen 
Signed-off-by: Greg Kroah-Hartman

arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

2021-11-02T18:48:22+00:00

commit 0764e365dacd0b8f75c1736f9236be280649bd18 upstream.

RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
node.

Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
Signed-off-by: Clément Bœsch 
Reviewed-by: Jernej Skrabec 
Reviewed-by: Andrew Lunn 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20210905002027.171984-1-u@pkh.me
Signed-off-by: Greg Kroah-Hartman

riscv, bpf: Fix potential NULL dereference

2021-11-02T18:48:21+00:00

commit 27de809a3d83a6199664479ebb19712533d6fd9b upstream.

The bpf_jit_binary_free() function requires a non-NULL argument. When
the RISC-V BPF JIT fails to converge in NR_JIT_ITERATIONS steps,
jit_data->header will be NULL, which triggers a NULL
dereference. Avoid this by checking the argument, prior calling the
function.

Fixes: ca6cb5447cec ("riscv, bpf: Factor common RISC-V JIT code")
Signed-off-by: Björn Töpel 
Acked-by: Daniel Borkmann 
Link: https://lore.kernel.org/r/20211028125115.514587-1-bjorn@kernel.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

arm64: Avoid premature usercopy failure

2021-11-02T18:48:18+00:00

commit 295cf156231ca3f9e3a66bde7fab5e09c41835e0 upstream.

Al reminds us that the usercopy API must only return complete failure
if absolutely nothing could be copied. Currently, if userspace does
something silly like giving us an unaligned pointer to Device memory,
or a size which overruns MTE tag bounds, we may fail to honour that
requirement when faulting on a multi-byte access even though a smaller
access could have succeeded.

Add a mitigation to the fixup routines to fall back to a single-byte
copy if we faulted on a larger access before anything has been written
to the destination, to guarantee making *some* forward progress. We
needn't be too concerned about the overall performance since this should
only occur when callers are doing something a bit dodgy in the first
place. Particularly broken userspace might still be able to trick
generic_perform_write() into an infinite loop by targeting write() at
an mmap() of some read-only device register where the fault-in load
succeeds but any store synchronously aborts such that copy_to_user() is
genuinely unable to make progress, but, well, don't do that...

CC: stable@vger.kernel.org
Reported-by: Chen Huang 
Suggested-by: Al Viro 
Reviewed-by: Catalin Marinas 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/dc03d5c675731a1f24a62417dba5429ad744234e.1626098433.git.robin.murphy@arm.com
Signed-off-by: Will Deacon 
Signed-off-by: Chen Huang 
Signed-off-by: Greg Kroah-Hartman

powerpc/bpf: Fix BPF_MOD when imm == 1

2021-11-02T18:48:18+00:00

commit 8bbc9d822421d9ac8ff9ed26a3713c9afc69d6c8 upstream.

Only ignore the operation if dividing by 1.

Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
Signed-off-by: Naveen N. Rao 
Tested-by: Johan Almbladh 
Reviewed-by: Christophe Leroy 
Acked-by: Song Liu 
Acked-by: Johan Almbladh 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Greg Kroah-Hartman

ARM: 9141/1: only warn about XIP address when not compile testing

2021-11-02T18:48:18+00:00

commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream.

In randconfig builds, we sometimes come across this warning:

arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

While this is helpful for actual systems to figure out why it
fails, the warning does not provide any benefit for build testing,
so guard it in a check for CONFIG_COMPILE_TEST, which is usually
set on randconfig builds.

Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Greg Kroah-Hartman