kernel/linux.git/arch/parisc, branch v7.0.11

ring-buffer: Flush and stop persistent ring buffer on panic

2026-06-01T15:54:24+00:00

commit a494d3c8d5392bcdff83c2a593df0c160ff9f322 upstream. On real hardware, panic and machine reboot may not flush hardware cache to memory. This means the persistent ring buffer, which relies on a coherent state of memory, may not have its events written to the buffer and they may be lost. Moreover, there may be inconsistency with the counters which are used for validation of the integrity of the persistent ring buffer which may cause all data to be discarded. To avoid this issue, stop recording of the ring buffer on panic and flush the cache of the ring buffer's memory. Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") Cc: stable@vger.kernel.org Cc: Will Deacon Cc: Mathieu Desnoyers Cc: Ian Rogers Link: https://patch.msgid.link/177751969602.2136606.12031934362587643488.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) Acked-by: Catalin Marinas Acked-by: Geert Uytterhoeven Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman

fs: fix archiecture-specific compat_ftruncate64

2026-05-23T11:08:26+00:00

[ Upstream commit e43dce8a0bc09083ea1145a1a0c61d83cbe72d97 ] The "small" argument to do_sys_ftruncate indicates if > 32-bit size should be reject, but all the arch-specific compat ftruncate64 implementations get this wrong. Merge do_sys_ftruncate and ksys_ftruncate, replace the integer as boolean small flag with a descriptive one about LFS semantics, and use it correctly in the architecture-specific ftruncate64 implementations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 3dd681d944f6 ("arm64: 32-bit (compat) applications support") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260323070205.2939118-2-hch@lst.de Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

module.lds.S: Fix modules on 32-bit parisc architecture

2026-05-07T04:13:54+00:00

commit 1221365f55281349da4f4ba41c05b57cd15f5c28 upstream. On the 32-bit parisc architecture, we always used the -ffunction-sections compiler option to tell the compiler to put the functions into seperate text sections. This is necessary, otherwise "big" kernel modules like ext4 or ipv6 fail to load because some branches won't be able to reach their stubs. Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") broke this for parisc because all text sections will get unconditionally merged now. Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which avoids the text section merge for modules, and fix this issue by enabling this option by default for 32-bit parisc. Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Cc: Josh Poimboeuf Cc: stable@vger.kernel.org # v6.19+ Suggested-by: Sami Tolvanen Reviewed-by: Petr Pavlu Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: Drop ip_fast_csum() inline assembly implementation

2026-05-07T04:13:51+00:00

commit 3dd31a370c1dccb580f729af7c580ccb1ae3c0c9 upstream. The assembly code of ip_fast_csum() triggers unaligned access warnings if the IP header isn't correctly aligned: Kernel: unaligned access to 0x173d22e76 in inet_gro_receive+0xbc/0x2e8 (iir 0x0e8810b6) Kernel: unaligned access to 0x173d22e7e in inet_gro_receive+0xc4/0x2e8 (iir 0x0e88109a) Kernel: unaligned access to 0x173d22e82 in inet_gro_receive+0xc8/0x2e8 (iir 0x0e90109d) Kernel: unaligned access to 0x173d22e7a in inet_gro_receive+0xd0/0x2e8 (iir 0x0e9810b8) Kernel: unaligned access to 0x173d22e86 in inet_gro_receive+0xdc/0x2e8 (iir 0x0e8810b8) We have the option to a) ignore the warnings, b) work around it by adding more code to check for alignment, or c) to switch to the generic implementation and rely on the compiler to optimize the code. Let's go with c), because a) isn't nice, and b) would effectively lead to an implementation which is basically equal to c). Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Greg Kroah-Hartman

parisc: _llseek syscall is only available for 32-bit userspace

2026-05-07T04:13:51+00:00

commit da3680f564bd787ce974f9931e6e924d908b3b2a upstream. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: Flush correct cache in cacheflush() syscall

2026-03-15T08:28:49+00:00

The assembly flush instructions were swapped for I- and D-cache flags: SYSCALL_DEFINE3(cacheflush, ...) { if (cache & DCACHE) { "fic ...\n" } if (cache & ICACHE && error == 0) { "fdc ...\n" } Fix it by using fdc for DCACHE, and fic for ICACHE flushing. Reported-by: Felix Lechner Fixes: c6d96328fecd ("parisc: Add cacheflush() syscall") Cc: # v6.5+ Signed-off-by: Helge Deller

Merge tag 'parisc-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux

2026-03-07T20:38:16+00:00

Pull parisc fixes from Helge Deller: "While testing Sasha Levin's 'kallsyms: embed source file:line info in kernel stack traces' patch series, which increases the typical kernel image size, I found some issues with the parisc initial kernel mapping which may prevent the kernel to boot. The three small patches here fix this" * tag 'parisc-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix initial page table creation for boot parisc: Check kernel mapping earlier at bootup parisc: Increase initial mapping to 64 MB with KALLSYMS

parisc: Fix initial page table creation for boot

2026-03-06T10:33:13+00:00

The KERNEL_INITIAL_ORDER value defines the initial size (usually 32 or 64 MB) of the page table during bootup. Up until now the whole area was initialized with PTE entries, but there was no check if we filled too many entries. Change the code to fill up with so many entries that the "_end" symbol can be reached by the kernel, but not more entries than actually fit into the initial PTE tables. Signed-off-by: Helge Deller Cc: # v6.0+

parisc: Check kernel mapping earlier at bootup

2026-03-06T10:33:13+00:00

The check if the initial mapping is sufficient needs to happen much earlier during bootup. Move this test directly to the start_parisc() function and use native PDC iodc functions to print the warning, because panic() and printk() are not functional yet. This fixes boot when enabling various KALLSYSMS options which need much more space. Signed-off-by: Helge Deller Cc: # v6.0+

parisc: Increase initial mapping to 64 MB with KALLSYMS

2026-03-06T10:33:13+00:00

The 32MB initial kernel mapping can become too small when CONFIG_KALLSYMS is used. Increase the mapping to 64 MB in this case. Signed-off-by: Helge Deller Cc: # v6.0+