kernel.git/arch/parisc/kernel/traps.c, branch linux-5.16.y

parisc: Fix handling off probe non-access faults

2022-04-08T12:06:34Z

[ Upstream commit e00b0a2ab8ec019c344e53bfc76e31c18bb587b7 ] Currently, the parisc kernel does not fully support non-access TLB fault handling for probe instructions. In the fast path, we set the target register to zero if it is not a shadowed register. The slow path is not implemented, so we call do_page_fault. The architecture indicates that non-access faults should not cause a page fault from disk. This change adds to code to provide non-access fault support for probe instructions. It also modifies the handling of faults on userspace so that if the address lies in a valid VMA and the access type matches that for the VMA, the probe target register is set to one. Otherwise, the target register is set to zero. This was done to make probe instructions more useful for userspace. Probe instructions are not very useful if they set the target register to zero whenever a page is not present in memory. Nominally, the purpose of the probe instruction is determine whether read or write access to a given address is allowed. This fixes a problem in function pointer comparison noticed in the glibc testsuite (stdio-common/tst-vfprintf-user-type). The same problem is likely in glibc (_dl_lookup_address). V2 adds flush and lpa instruction support to handle_nadtlb_fault. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

parisc: Avoid calling faulthandler_disabled() twice

2022-01-27T11:02:31Z

[ Upstream commit 9e9d4b460f23bab61672eae397417d03917d116c ] In handle_interruption(), we call faulthandler_disabled() to check whether the fault handler is not disabled. If the fault handler is disabled, we immediately call do_page_fault(). It then calls faulthandler_disabled(). If disabled, do_page_fault() attempts to fixup the exception by jumping to no_context: no_context: if (!user_mode(regs) && fixup_exception(regs)) { return; } parisc_terminate("Bad Address (null pointer deref?)", regs, code, address); Apart from the error messages, the two blocks of code perform the same function. We can avoid two calls to faulthandler_disabled() by a simple revision to the code in handle_interruption(). Note: I didn't try to fix the formatting of this code block. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

parisc: Clear stale IIR value on instruction access rights trap

2021-12-20T13:38:40Z

When a trap 7 (Instruction access rights) occurs, this means the CPU couldn't execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didn't even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19. This patch simply overwrites the stale IIR value with a constant magic "bad food" value (0xbaadf00d), in the hope people don't start to try to understand the various random IIR values in trap 7 dumps. Noticed-by: John David Anglin Signed-off-by: Helge Deller

parisc: don't enable irqs unconditionally in handle_interruption()

2021-11-04T10:21:20Z

If the previous context had interrupts disabled, we should better keep them disabled. This was noticed in the unwinding code where a copy_from_kernel_nofault() triggered a page fault, and after the fixup by the page fault handler interrupts where suddenly enabled. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller

parisc: Move thread_info into task struct

2021-11-01T06:35:59Z

This implements the CONFIG_THREAD_INFO_IN_TASK option. With this change: - before thread_info was part of the stack and located at the beginning of the stack - now the thread_info struct is moved and located inside the task_struct structure - the stack is allocated and handled like the major other platforms - drop the cpu field of thread_info and use instead the one in task_struct Signed-off-by: Helge Deller Signed-off-by: Sven Schnelle

parisc: Add KFENCE support

2021-10-30T21:11:00Z

Signed-off-by: Helge Deller

trap: cleanup trap_init()

2021-09-08T18:50:27Z

There are some empty trap_init() definitions in different ARCHs, Introduce a new weak trap_init() function to clean them up. Link: https://lkml.kernel.org/r/20210812123602.76356-1-wangkefeng.wang@huawei.com Signed-off-by: Kefeng Wang Acked-by: Russell King (Oracle) [arm32] Acked-by: Vineet Gupta [arc] Acked-by: Michael Ellerman [powerpc] Cc: Yoshinori Sato Cc: Ley Foon Tan Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: James E.J. Bottomley Cc: Helge Deller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Paul Walmsley Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

parisc: Fix IVT checksum calculation wrt HPMC

2021-02-12T15:31:42Z

On my C8000 a HPMC was triggered, but the HPMC handler wasn't called. I got the following chassis codes: e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC e800009803e00000 00000000001b28a3 CC_ERR_CHECK_HPMC 37000f7302e00000 8400000000800000 CC_ERR_CPU_CHECK_SUMMARY 37000f7303e00000 8400000000800000 CC_ERR_CPU_CHECK_SUMMARY f600105e02e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED 5600100b03e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR 140003b202e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY 5600106403e00000 fffffff0f043ad20 CC_MC_BR_TO_OS_HPMC_FAILED 160012cf03e00000 030001001e000007 CC_MPS_CPU_WAITING 5600100b02e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR 5600106402e00000 fffffff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC 37000f7302e00000 8400000000800000 CC_ERR_CPU_CHECK_SUMMARY 4000109f02e00000 0000000000000000 CC_MC_HPMC_INITIATED 4000101902e00000 0000000000000000 CC_MC_MULTIPLE_HPMCS 030010d502e00000 0000000000000000 CC_CPU_STOP C8000 PDC is complaining about our HPMC handler length, which is 1a0 (second part of the chassis code). Changing that to 0 makes the error go away: e800009800e00000 0000000000000000 CC_ERR_CHECK_HPMC e800009803e00000 0000000000000000 CC_ERR_CHECK_HPMC e800009801e00000 0000000000000000 CC_ERR_CHECK_HPMC e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC 37000f7300e00000 8060004000000000 CC_ERR_CPU_CHECK_SUMMARY 37000f7303e00000 8060004000000000 CC_ERR_CPU_CHECK_SUMMARY 37000f7301e00000 8060004000000000 CC_ERR_CPU_CHECK_SUMMARY 37000f7302e00000 8060004000000000 CC_ERR_CPU_CHECK_SUMMARY f600105e00e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED 5600109b03e00000 00000000001eb024 CC_MC_BR_TO_OS_HPMC 5600109b01e00000 00000000001eb024 CC_MC_BR_TO_OS_HPMC 5600109b02e00000 00000000001eb024 CC_MC_BR_TO_OS_HPMC 140003b200e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY 0000000003000000 0000000000000000 0000000001000000 0000000000000000 0000000002000000 0000000000000000 5600109b00e00000 00000000001eb024 CC_MC_BR_TO_OS_HPMC 0000000000000000 0000000000000000 So at least the HPMC handler is now called, but it hangs. Which isn't really suprising, as the code has at least one comment saying it can't handle multiple CPUs, and here the handler is called on all CPUs. And i'm not sure whether it can handle 64 Bit. So despite what the PDC spec says, C8000 and RP34xx/RP44xx don't want the OS_HPMC length in the vector set, which is odd. I disassembled the firmware and it actually looks like a Bug in PDC. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59Z

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva

parisc: make the log level string for register dumps const

2020-08-04T14:22:53Z

Signed-off-by: Rolf Eike Beer Signed-off-by: Helge Deller