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

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+

kbuild: Split .modinfo out from ELF_DETAILS

2026-02-26T18:50:19+00:00

Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo to ELF_DETAILS while removing it from COMMON_DISCARDS, as it was needed in vmlinux.unstripped and ELF_DETAILS was present in all architecture specific vmlinux linker scripts. While this shuffle is fine for vmlinux, ELF_DETAILS and COMMON_DISCARDS may be used by other linker scripts, such as the s390 and x86 compressed boot images, which may not expect to have a .modinfo section. In certain circumstances, this could result in a bootloader failing to load the compressed kernel [1]. Commit ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with SecureBoot trailer") recently addressed this for the s390 bzImage but the same bug remains for arm, parisc, and x86. The presence of .modinfo in the x86 bzImage was the root cause of the issue worked around with commit d50f21091358 ("kbuild: align modinfo section for Secureboot Authenticode EDK2 compat"). misc.c in arch/x86/boot/compressed includes lib/decompress_unzstd.c, which in turn includes lib/xxhash.c and its MODULE_LICENSE / MODULE_DESCRIPTION macros due to the STATIC definition. Split .modinfo out from ELF_DETAILS into its own macro and handle it in all vmlinux linker scripts. Discard .modinfo in the places where it was previously being discarded from being in COMMON_DISCARDS, as it has never been necessary in those uses. Cc: stable@vger.kernel.org Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Reported-by: Ed W Closes: https://lore.kernel.org/587f25e0-a80e-46a5-9f01-87cb40cfa377@wildgooses.com/ [1] Tested-by: Ed W # x86_64 Link: https://patch.msgid.link/20260225-separate-modinfo-from-elf-details-v1-1-387ced6baf4b@kernel.org Signed-off-by: Nathan Chancellor