kernel.git/arch/parisc/kernel/asm-offsets.c, branch linux-6.19.y

parisc: entry: set W bit for !compat tasks in syscall_restore_rfi()

2025-10-15T23:37:39Z

When the kernel leaves to userspace via syscall_restore_rfi(), the W bit is not set in the new PSW. This doesn't cause any problems because there's no 64 bit userspace for parisc. Simple static binaries are usually loaded at addresses way below the 32 bit limit so the W bit doesn't matter. Fix this by setting the W bit when TIF_32BIT is not set. Signed-off-by: Sven Schnelle Cc: stable@vger.kernel.org Signed-off-by: Helge Deller

arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c

2025-09-25T07:57:15Z

The include/generated/asm-offsets.h is generated in Kbuild during compiling from arch/SRCARCH/kernel/asm-offsets.c. When we want to generate another similar offset header file, circular dependency can happen. For example, we want to generate a offset file include/generated/test.h, which is included in include/sched/sched.h. If we generate asm-offsets.h first, it will fail, as include/sched/sched.h is included in asm-offsets.c and include/generated/test.h doesn't exist; If we generate test.h first, it can't success neither, as include/generated/asm-offsets.h is included by it. In x86_64, the macro COMPILE_OFFSETS is used to avoid such circular dependency. We can generate asm-offsets.h first, and if the COMPILE_OFFSETS is defined, we don't include the "generated/test.h". And we define the macro COMPILE_OFFSETS for all the asm-offsets.c for this purpose. Signed-off-by: Menglong Dong Signed-off-by: Peter Zijlstra (Intel)

parisc: Prepare for Block-TLB support on 32-bit kernel

2023-09-07T07:12:19Z

Change HUGEPAGE_SIZE to become 4 MB on 32-bit kernels, which leads that kernel code and kernel data will start on 4 MB boundaries. Although a 32-bit kernel does not support huge pages, most machines have support for Block-TLBs (BTLB) which allow to configure the system to use large pages (block TLBs) to minimize the TLB contention. This is done through calls to PDC and the 32-bit kernel can then call BTLB PDC functions to tell the machine to optimize the TLBs. Signed-off-by: Helge Deller

parisc: Fix vDSO signal breakage on 32-bit kernel

2022-07-02T16:36:58Z

Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc signal testcases on a 32-bit kernel. The trampoline code (sigtramp.S) which is mapped into userspace includes an offset to the context data on the stack, which is used by gdb and glibc to get access to registers. In a 32-bit kernel we used by mistake the offset into the compat context (which is valid on a 64-bit kernel only) instead of the offset into the "native" 32-bit context. Reported-by: John David Anglin Tested-by: John David Anglin Fixes: df24e1783e6e ("parisc: Add vDSO support") CC: stable@vger.kernel.org # 5.18 Signed-off-by: Helge Deller

parisc: Add vDSO support

2022-03-11T18:49:30Z

Add minimal vDSO support, which provides the signal trampoline helpers, but none of the userspace syscall helpers like time wrappers. The big benefit of this vDSO implementation is, that we now don't need an executeable stack any longer. PA-RISC is one of the last architectures where an executeable stack was needed in oder to implement the signal trampolines by putting assembly instructions on the stack which then gets executed. Instead the kernel will provide the relevant code in the vDSO page and only put the pointers to the signal information on the stack. By dropping the need for executable stacks we avoid running into issues with applications which want non executable stacks for security reasons. Additionally, alternative stacks on memory areas without exec permissions are supported too. This code is based on an initial implementation by Randolph Chung from 2006: https://lore.kernel.org/linux-parisc/4544A34A.6080700@tausq.org/ I did the porting and lifted the code to current code base. Dave fixed the unwind code so that gdb and glibc are able to backtrace through the code. An additional patch to gdb will be pushed upstream by Dave. Signed-off-by: Helge Deller Signed-off-by: Dave Anglin Cc: Randolph Chung Signed-off-by: Helge Deller

parisc: Enable TOC (transfer of contents) feature unconditionally

2022-01-11T10:57:37Z

Before this patch, the TOC code used a pre-allocated stack of 16kb for each possible CPU. That space overhead was the reason why the TOC feature wasn't enabled by default for 32-bit kernels. This patch rewrites the TOC code to use a per-cpu stack. That way we use much less memory now and as such we enable the TOC feature by default on all kernels. Additionally the dump of the registers and the stacktrace wasn't serialized, which led to multiple CPUs printing the stack backtrace at once which rendered the output unreadable. Now the backtraces are nicely serialized by a lock. Signed-off-by: Helge Deller

parisc: Rewrite light-weight syscall and futex code

2022-01-07T00:29:21Z

The parisc architecture lacks general hardware support for compare and swap. Particularly for userspace, it is difficult to implement software atomic support. Page faults in critical regions can cause processes to sleep and block the forward progress of other processes. Thus, it is essential that page faults be disabled in critical regions. For performance reasons, we also need to disable external interrupts in critical regions. In order to do this, we need a mechanism to trigger COW breaks outside the critical region. Fortunately, parisc has the "stbys,e" instruction. When the leftmost byte of a word is addressed, this instruction triggers all the exceptions of a normal store but it does not write to memory. Thus, we can use it to trigger COW breaks outside the critical region without modifying the data that is to be updated atomically. COW breaks occur randomly. So even if we have priviously executed a "stbys,e" instruction, we still need to disable pagefaults around the critical region. If a fault occurs in the critical region, we return -EAGAIN. I had to add a wrapper around _arch_futex_atomic_op_inuser() as I found in testing that returning -EAGAIN caused problems for some processes even though it is listed as a possible return value. The patch implements the above. The code no longer attempts to sleep with interrupts disabled and I haven't seen any stalls with the change. I have attempted to merge common code and streamline the fast path. In the futex code, we only compute the spinlock address once. I eliminated some debug code in the original CAS routine that just made the flow more complicated. I don't clip the arguments when called from wide mode. As a result, the LWS routines should work when called from 64-bit processes. I defined TASK_PAGEFAULT_DISABLED offset for use in the lws_pagefault_disable and lws_pagefault_enable macros. Since we now disable interrupts on the gateway page where necessary, it might be possible to allow processes to be scheduled when they are on the gateway page. Change has been tested on c8000 and rp3440. It improves glibc build and test time by about 10%. In v2, I removed the lws_atomic_xchg and and lws_atomic_store calls. I also removed the bug fixes that were not directly related to this patch. In v3, I removed the code to force interruptions from arch_futex_atomic_op_inuser(). It is always called with page faults disabled, so this code had no effect. In v4, I fixed a typo in depi_safe line. In v5, I moved the code to disable/enable page faults inside the spinlocks. Signed-off-by: John David Anglin Signed-off-by: Helge Deller

parisc: move CPU field back into thread_info

2021-11-04T10:21:47Z

In commit 2214c0e77259 ("parisc: Move thread_info into task struct") PA-RISC gained support for THREAD_INFO_IN_TASK while changes were already underway to keep the CPU field in thread_info rather than move it into task_struct when THREAD_INFO_IN_TASK is enabled. The result is a broken build for all PA-RISC configs that enable SMP. So let's partially revert that commit, and get rid of the ugly hack to get at the offset of task_struct::cpu without having to include linux/sched.h, and put the CPU field back where it was before. Reported-by: Guenter Roeck Fixes: bcf9033e5449 ("sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y") Signed-off-by: Ard Biesheuvel Signed-off-by: Helge Deller

parisc: Remove unused constants from asm-offsets.c

2021-11-01T06:36:01Z

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