kernel.git/arch/m68k, branch linux-4.14.y

m68k: Fix invalid .section syntax

2023-09-23T08:46:53Z

[ Upstream commit 922a9bd138101e3e5718f0f4d40dba68ef89bb43 ] gas supports several different forms for .section for ELF targets, including: .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]] and: .section "NAME"[, #FLAGS...] In several places we use a mix of these two forms: .section NAME, #FLAGS... A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error. Change to consistently use: .section NAME, "FLAGS" as is used elsewhere in the kernel. Link: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1 Signed-off-by: Ben Hutchings Tested-by: Jan-Benedict Glaw Link: https://lore.kernel.org/r/ZIyBaueWT9jnTwRC@decadent.org.uk Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

m68k/cpu: Switch to arch_cpu_finalize_init()

2023-08-08T17:48:23Z

commit 9ceecc2589b9d7cef6b321339ed8de484eac4b20 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner Acked-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230613224545.254342916@linutronix.de Signed-off-by: Daniel Sneddon Signed-off-by: Greg Kroah-Hartman

m68k: Move signal frame following exception on 68020/030

2023-05-30T11:38:37Z

commit b845b574f86dcb6a70dfa698aa87a237b0878d2a upstream. On 68030/020, an instruction such as, moveml %a2-%a3/%a5,%sp@- may cause a stack page fault during instruction execution (i.e. not at an instruction boundary) and produce a format 0xB exception frame. In this situation, the value of USP will be unreliable. If a signal is to be delivered following the exception, this USP value is used to calculate the location for a signal frame. This can result in a corrupted user stack. The corruption was detected in dash (actually in glibc) where it showed up as an intermittent "stack smashing detected" message and crash following signal delivery for SIGCHLD. It was hard to reproduce that failure because delivery of the signal raced with the page fault and because the kernel places an unpredictable gap of up to 7 bytes between the USP and the signal frame. A format 0xB exception frame can be produced by a bus error or an address error. The 68030 Users Manual says that address errors occur immediately upon detection during instruction prefetch. The instruction pipeline allows prefetch to overlap with other instructions, which means an address error can arise during the execution of a different instruction. So it seems likely that this patch may help in the address error case also. Reported-and-tested-by: Stan Johnson Link: https://lore.kernel.org/all/CAMuHMdW3yD22_ApemzW_6me3adq6A458u1_F0v-1EYwK_62jPA@mail.gmail.com/ Cc: Michael Schmitz Cc: Andreas Schwab Cc: stable@vger.kernel.org Co-developed-by: Michael Schmitz Signed-off-by: Michael Schmitz Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/9e66262a754fcba50208aa424188896cc52a1dd1.1683365892.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

m68k: Only force 030 bus error if PC not in exception table

2023-04-05T09:14:17Z

[ Upstream commit e36a82bebbf7da814530d5a179bef9df5934b717 ] __get_kernel_nofault() does copy data in supervisor mode when forcing a task backtrace log through /proc/sysrq_trigger. This is expected cause a bus error exception on e.g. NULL pointer dereferencing when logging a kernel task has no workqueue associated. This bus error ought to be ignored. Our 030 bus error handler is ill equipped to deal with this: Whenever ssw indicates a kernel mode access on a data fault, we don't even attempt to handle the fault and instead always send a SEGV signal (or panic). As a result, the check for exception handling at the fault PC (buried in send_sig_fault() which gets called from do_page_fault() eventually) is never used. In contrast, both 040 and 060 access error handlers do not care whether a fault happened on supervisor mode access, and will call do_page_fault() on those, ultimately honoring the exception table. Add a check in bus_error030 to call do_page_fault() in case we do have an entry for the fault PC in our exception table. I had attempted a fix for this earlier in 2019 that did rely on testing pagefault_disabled() (see link below) to achieve the same thing, but this patch should be more generic. Tested on 030 Atari Falcon. Reported-by: Eero Tamminen Link: https://lore.kernel.org/r/alpine.LNX.2.21.1904091023540.25@nippy.intranet Link: https://lore.kernel.org/r/63130691-1984-c423-c1f2-73bfd8d3dcd3@gmail.com Signed-off-by: Michael Schmitz Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230301021107.26307-1-schmitzmic@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

m68k: Check syscall_trace_enter() return code

2023-03-11T15:26:42Z

[ Upstream commit 2ca8a1de4437f21562e57f9ac123914747a8e7a1 ] Check return code of syscall_trace_enter(), and skip syscall if -1. Return code will be left at what had been set by ptrace or seccomp (in regs->d0). No regression seen in testing with strace on ARAnyM. Signed-off-by: Michael Schmitz Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230112035529.13521-2-schmitzmic@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

m68k: /proc/hardware should depend on PROC_FS

2023-03-11T15:26:37Z

[ Upstream commit 1e5b5df65af99013b4d31607ddb3ca5731dbe44d ] When CONFIG_PROC_FS is not set, there is a build error for an unused function. Make PROC_HARDWARE depend on PROC_FS to prevent this error. In file included from ../arch/m68k/kernel/setup.c:3: ../arch/m68k/kernel/setup_mm.c:477:12: error: 'hardware_proc_show' defined but not used [-Werror=unused-function] 477 | static int hardware_proc_show(struct seq_file *m, void *v) | ^~~~~~~~~~~~~~~~~~ Fixes: 66d857b08b8c ("m68k: merge m68k and m68knommu arch directories") # v3.0 Signed-off-by: Randy Dunlap Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230209010825.24136-1-rdunlap@infradead.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

exit: Add and use make_task_dead.

2023-02-06T06:46:33Z

commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream. There are two big uses of do_exit. The first is it's design use to be the guts of the exit(2) system call. The second use is to terminate a task after something catastrophic has happened like a NULL pointer in kernel code. Add a function make_task_dead that is initialy exactly the same as do_exit to cover the cases where do_exit is called to handle catastrophic failure. In time this can probably be reduced to just a light wrapper around do_task_dead. For now keep it exactly the same so that there will be no behavioral differences introducing this new concept. Replace all of the uses of do_exit that use it for catastraphic task cleanup with make_task_dead to make it clear what the code is doing. As part of this rename rewind_stack_do_exit rewind_stack_and_make_dead. Signed-off-by: "Eric W. Biederman" Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

m68k: use fallback for random_get_entropy() instead of zero

2022-06-25T09:46:38Z

commit 0f392c95391f2d708b12971a07edaa7973f9eece upstream. In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though random_get_entropy_fallback() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Thomas Gleixner Cc: Arnd Bergmann Acked-by: Geert Uytterhoeven Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

m68knommu: fix undefined reference to `_init_sp'

2022-06-14T14:53:58Z

[ Upstream commit a71b9e66fee47c59b3ec34e652b5c23bc6550794 ] When configuring a nommu classic m68k system enabling the uboot parameter passing support (CONFIG_UBOOT) will produce the following compile error: m68k-linux-ld: arch/m68k/kernel/uboot.o: in function `process_uboot_commandline': uboot.c:(.init.text+0x32): undefined reference to `_init_sp' The logic to support this option is only used on ColdFire based platforms (in its head.S startup code). So make the selection of this option depend on building for a ColdFire based platform. Reported-by: kernel test robot Reviewed-by: Geert Uytterhoeven Acked-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin

m68knommu: set ZERO_PAGE() to the allocated zeroed page

2022-06-14T14:53:58Z

[ Upstream commit dc068f46217970d9516f16cd37972a01d50dc055 ] The non-MMU m68k pagetable ZERO_PAGE() macro is being set to the somewhat non-sensical value of "virt_to_page(0)". The zeroth page is not in any way guaranteed to be a page full of "0". So the result is that ZERO_PAGE() will almost certainly contain random values. We already allocate a real "empty_zero_page" in the mm setup code shared between MMU m68k and non-MMU m68k. It is just not hooked up to the ZERO_PAGE() macro for the non-MMU m68k case. Fix ZERO_PAGE() to use the allocated "empty_zero_page" pointer. I am not aware of any specific issues caused by the old code. Link: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#t Reported-by: Hugh Dickens Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin