kernel/linux.git/arch, branch v5.6.15

x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasks

2020-05-27T15:48:29+00:00

commit 187b96db5ca79423618dfa29a05c438c34f9e1f0 upstream. Normally, show_trace_log_lvl() scans the stack, looking for text addresses to print. In parallel, it unwinds the stack with unwind_next_frame(). If the stack address matches the pointer returned by unwind_get_return_address_ptr() for the current frame, the text address is printed normally without a question mark. Otherwise it's considered a breadcrumb (potentially from a previous call path) and it's printed with a question mark to indicate that the address is unreliable and typically can be ignored. Since the following commit: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") ... for inactive tasks, show_trace_log_lvl() prints *only* unreliable addresses (prepended with '?'). That happens because, for the first frame of an inactive task, unwind_get_return_address_ptr() returns the wrong return address pointer: one word *below* the task stack pointer. show_trace_log_lvl() starts scanning at the stack pointer itself, so it never finds the first 'reliable' address, causing only guesses to being printed. The first frame of an inactive task isn't a normal stack frame. It's actually just an instance of 'struct inactive_task_frame' which is left behind by __switch_to_asm(). Now that this inactive frame is actually exposed to callers, fix unwind_get_return_address_ptr() to interpret it properly. Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Reported-by: Tetsuo Handa Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200522135435.vbxs7umku5pyrdbk@treble Signed-off-by: Greg Kroah-Hartman

s390/kexec_file: fix initrd location for kdump kernel

2020-05-27T15:48:29+00:00

commit 70b690547d5ea1a3d135a4cc39cd1e08246d0c3a upstream. initrd_start must not point at the location the initrd is loaded into the crashkernel memory but at the location it will be after the crashkernel memory is swapped with the memory at 0. Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader") Reported-by: Lianbo Jiang Signed-off-by: Philipp Rudo Tested-by: Lianbo Jiang Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local Signed-off-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman

sparc32: fix page table traversal in srmmu_nocache_init()

2020-05-27T15:48:27+00:00

commit 0cfc8a8d70dcd51db783e8e87917e02149c71458 upstream. The srmmu_nocache_init() uses __nocache_fix() macro to add an offset to page table entry to access srmmu_nocache_pool. But since sparc32 has only three actual page table levels, pgd, p4d and pud are essentially the same thing and pgd_offset() and p4d_offset() are no-ops, the __nocache_fix() should be done only at PUD level. Remove __nocache_fix() for p4d_offset() and pud_offset() and keep it only for PUD and lower levels. Fixes: c2bc26f7ca1f ("sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()") Signed-off-by: Mike Rapoport Cc: David S. Miller Cc: Anatoly Pugachev Cc: Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()

2020-05-27T15:48:26+00:00

commit c2bc26f7ca1ff1165bb6669a7a4cccc20ffd2ced upstream. The kbuild test robot reported the following warning: arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init': arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used [-Werror=unused-but-set-variable] 300 | pud_t *pud; This warning is caused by misprint in the page table traversal in srmmu_nocache_init() function which accessed a PMD entry using PGD rather than PUD. Since sparc32 has only 3 page table levels, the PGD and PUD are essentially the same and usage of __nocache_fix() removed the type checking. Use PUD for the consistency and to silence the compiler warning. Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup") Reported-by: kbuild test robot Signed-off-by: Mike Rapoport Signed-off-by: Andrew Morton Cc: David S. Miller Cc: Anatoly Pugachev Cc: Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sh: include linux/time_types.h for sockios

2020-05-27T15:48:26+00:00

commit fc94cf2092c7c1267fa2deb8388d624f50eba808 upstream. Using the socket ioctls on arch/sh (and only there) causes build time problems when __kernel_old_timeval/__kernel_old_timespec are not already visible to the compiler. Add an explict include line for the header that defines these structures. Fixes: 8c709f9a0693 ("y2038: sh: remove timeval/timespec usage from headers") Fixes: 0768e17073dc ("net: socket: implement 64-bit timestamps") Reported-by: John Paul Adrian Glaubitz Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Tested-by: John Paul Adrian Glaubitz Cc: Yoshinori Sato Cc: Rich Felker Cc: "David S. Miller" Cc: John Paul Adrian Glaubitz Cc: Link: http://lkml.kernel.org/r/20200519131327.1836482-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

s390/kaslr: add support for R_390_JMP_SLOT relocation type

2020-05-27T15:48:25+00:00

commit 4c1cbcbd6c56c79de2c07159be4f55386bb0bef2 upstream. With certain kernel configurations, the R_390_JMP_SLOT relocation type might be generated, which is not expected by the KASLR relocation code, and the kernel stops with the message "Unknown relocation type". This was found with a zfcpdump kernel config, where CONFIG_MODULES=n and CONFIG_VFIO=n. In that case, symbol_get() is used on undefined __weak symbols in virt/kvm/vfio.c, which results in the generation of R_390_JMP_SLOT relocation types. Fix this by handling R_390_JMP_SLOT similar to R_390_GLOB_DAT. Fixes: 805bc0bc238f ("s390/kernel: build a relocatable kernel") Cc: # v5.2+ Signed-off-by: Gerald Schaefer Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman

s390/pci: Fix s390_mmio_read/write with MIO

2020-05-27T15:48:25+00:00

commit f058599e22d59e594e5aae1dc10560568d8f4a8b upstream. The s390_mmio_read/write syscalls are currently broken when running with MIO. The new pcistb_mio/pcstg_mio/pcilg_mio instructions are executed similiarly to normal load/store instructions and do address translation in the current address space. That means inside the kernel they are aware of mappings into kernel address space while outside the kernel they use user space mappings (usually created through mmap'ing a PCI device file). Now when existing user space applications use the s390_pci_mmio_write and s390_pci_mmio_read syscalls, they pass I/O addresses that are mapped into user space so as to be usable with the new instructions without needing a syscall. Accessing these addresses with the old instructions as done currently leads to a kernel panic. Also, for such a user space mapping there may not exist an equivalent kernel space mapping which means we can't just use the new instructions in kernel space. Instead of replicating user mappings in the kernel which then might collide with other mappings, we can conceptually execute the new instructions as if executed by the user space application using the secondary address space. This even allows us to directly store to the user pointer without the need for copy_to/from_user(). Cc: stable@vger.kernel.org Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Niklas Schnelle Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman

powerpc/64s: Disable STRICT_KERNEL_RWX

2020-05-27T15:48:17+00:00

commit 8659a0e0efdd975c73355dbc033f79ba3b31e82c upstream. Several strange crashes have been eventually traced back to STRICT_KERNEL_RWX and its interaction with code patching. Various paths in our ftrace, kprobes and other patching code need to be hardened against patching failures, otherwise we can end up running with partially/incorrectly patched ftrace paths, kprobes or jump labels, which can then cause strange crashes. Although fixes for those are in development, they're not -rc material. There also seem to be problems with the underlying strict RWX logic, which needs further debugging. So for now disable STRICT_KERNEL_RWX on 64-bit to prevent people from enabling the option and tripping over the bugs. Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200520133605.972649-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman

arm64: Fix PTRACE_SYSEMU semantics

2020-05-27T15:48:16+00:00

commit 1cf6022bd9161081215028203919c33fcfa6debb upstream. Quoth the man page: ``` If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the tracee enters syscall-enter-stop just prior to entering any system call (which will not be executed if the restart was using PTRACE_SYSEMU, regardless of any change made to registers at this point or how the tracee is restarted after this stop). ``` The parenthetical comment is currently true on x86 and powerpc, but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU flag after the syscall entry ptrace stop. However, at this point, it reflects which method was used to re-start the syscall at the entry stop, rather than the method that was used to reach it. Fix that by recording the original flag before performing the ptrace stop, bringing the behavior in line with documentation and x86/powerpc. Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") Cc: # 5.3.x- Signed-off-by: Keno Fischer Acked-by: Will Deacon Tested-by: Sudeep Holla Tested-by: Bin Lu [catalin.marinas@arm.com: moved 'flags' bit masking] [catalin.marinas@arm.com: changed 'flags' type to unsigned long] Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman

bpf: Restrict bpf_probe_read{, str}() only to archs where they work

2020-05-27T15:48:14+00:00

commit 0ebeea8ca8a4d1d453ad299aef0507dab04f6e8d upstream. Given the legacy bpf_probe_read{,str}() BPF helpers are broken on archs with overlapping address ranges, we should really take the next step to disable them from BPF use there. To generally fix the situation, we've recently added new helper variants bpf_probe_read_{user,kernel}() and bpf_probe_read_{user,kernel}_str(). For details on them, see 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user,kernel}_str helpers"). Given bpf_probe_read{,str}() have been around for ~5 years by now, there are plenty of users at least on x86 still relying on them today, so we cannot remove them entirely w/o breaking the BPF tracing ecosystem. However, their use should be restricted to archs with non-overlapping address ranges where they are working in their current form. Therefore, move this behind a CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE and have x86, arm64, arm select it (other archs supporting it can follow-up on it as well). For the remaining archs, they can workaround easily by relying on the feature probe from bpftool which spills out defines that can be used out of BPF C code to implement the drop-in replacement for old/new kernels via: bpftool feature probe macro Suggested-by: Linus Torvalds Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Reviewed-by: Masami Hiramatsu Acked-by: Linus Torvalds Cc: Brendan Gregg Cc: Christoph Hellwig Link: https://lore.kernel.org/bpf/20200515101118.6508-2-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman