user/sven/linux.git/arch, branch v6.12.4

powerpc: Adjust adding stack protector flags to KBUILD_CLAGS for clang

2024-12-09T09:41:10Z

commit bee08a9e6ab03caf14481d97b35a258400ffab8f upstream. After fixing the HAVE_STACKPROTECTER checks for clang's in-progress per-task stack protector support [1], the build fails during prepare0 because '-mstack-protector-guard-offset' has not been added to KBUILD_CFLAGS yet but the other '-mstack-protector-guard' flags have. clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default make[4]: *** [scripts/Makefile.build:229: scripts/mod/empty.o] Error 1 make[4]: *** [scripts/Makefile.build:102: scripts/mod/devicetable-offsets.s] Error 1 Mirror other architectures and add all '-mstack-protector-guard' flags to KBUILD_CFLAGS atomically during stack_protector_prepare, which resolves the issue and allows clang's implementation to fully work with the kernel. Cc: stable@vger.kernel.org # 6.1+ Link: https://github.com/llvm/llvm-project/pull/110928 [1] Reviewed-by: Keith Packard Tested-by: Keith Packard Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-2-12fb86b31857@kernel.org Signed-off-by: Greg Kroah-Hartman

powerpc: Fix stack protector Kconfig test for clang

2024-12-09T09:41:10Z

commit 46e1879deea22eed31e9425d58635895fc0e8040 upstream. Clang's in-progress per-task stack protector support [1] does not work with the current Kconfig checks because '-mstack-protector-guard-offset' is not provided, unlike all other architecture Kconfig checks. $ fd Kconfig -x rg -l mstack-protector-guard-offset ./arch/arm/Kconfig ./arch/riscv/Kconfig ./arch/arm64/Kconfig This produces an error from clang, which is interpreted as the flags not being supported at all when they really are. $ clang --target=powerpc64-linux-gnu \ -mstack-protector-guard=tls \ -mstack-protector-guard-reg=r13 \ -c -o /dev/null -x c /dev/null clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default This argument will always be provided by the build system, so mirror other architectures and use '-mstack-protector-guard-offset=0' for testing support, which fixes the issue for clang and does not regress support with GCC. Even with the first problem addressed, the 32-bit test continues to fail because Kbuild uses the powerpc64le-linux-gnu target for clang and nothing flips the target to 32-bit, resulting in an error about an invalid register valid: $ clang --target=powerpc64le-linux-gnu \ -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 \ -mstack-protector-guard-offset=0 \ -x c -c -o /dev/null /dev/null clang: error: invalid value 'r2' in 'mstack-protector-guard-reg=', expected one of: r13 While GCC allows arbitrary registers, the implementation of '-mstack-protector-guard=tls' in LLVM shares the same code path as the user space thread local storage implementation, which uses a fixed register (2 for 32-bit and 13 for 62-bit), so the command line parsing enforces this limitation. Use the Kconfig macro '$(m32-flag)', which expands to '-m32' when supported, in the stack protector support cc-option call to properly switch the target to a 32-bit one, which matches what happens in Kbuild. While the 64-bit macro does not strictly need it, add the equivalent 64-bit option for symmetry. Cc: stable@vger.kernel.org # 6.1+ Link: https://github.com/llvm/llvm-project/pull/110928 [1] Reviewed-by: Keith Packard Tested-by: Keith Packard Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-1-12fb86b31857@kernel.org Signed-off-by: Greg Kroah-Hartman

s390/stacktrace: Use break instead of return statement

2024-12-09T09:41:06Z

commit 588a9836a4ef7ec3bfcffda526dfa399637e6cfc upstream. arch_stack_walk_user_common() contains a return statement instead of a break statement in case store_ip() fails while trying to store a callchain entry of a user space process. This may lead to a missing pagefault_enable() call. If this happens any subsequent page fault of the process won't be resolved by the page fault handler and this in turn will lead to the process being killed. Use a break instead of a return statement to fix this. Fixes: ebd912ff9919 ("s390/stacktrace: Merge perf_callchain_user() and arch_stack_walk_user()") Cc: stable@vger.kernel.org Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

ARM: 9431/1: mm: Pair atomic_set_release() with _read_acquire()

2024-12-09T09:41:03Z

commit 93ee385254d53849c01dd8ab9bc9d02790ee7f0e upstream. The code for syncing vmalloc memory PGD pointers is using atomic_read() in pair with atomic_set_release() but the proper pairing is atomic_read_acquire() paired with atomic_set_release(). This is done to clearly instruct the compiler to not reorder the memcpy() or similar calls inside the section so that we do not observe changes to init_mm. memcpy() calls should be identified by the compiler as having unpredictable side effects, but let's try to be on the safe side. Cc: stable@vger.kernel.org Fixes: d31e23aff011 ("ARM: mm: make vmalloc_seq handling SMP safe") Suggested-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

ARM: 9430/1: entry: Do a dummy read from VMAP shadow

2024-12-09T09:41:03Z

commit 44e9a3bb76e5f2eecd374c8176b2c5163c8bb2e2 upstream. When switching task, in addition to a dummy read from the new VMAP stack, also do a dummy read from the VMAP stack's corresponding KASAN shadow memory to sync things up in the new MM context. Cc: stable@vger.kernel.org Fixes: a1c510d0adc6 ("ARM: implement support for vmap'ed stacks") Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/ Reported-by: Clement LE GOFFIC Suggested-by: Ard Biesheuvel Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

s390/entry: Mark IRQ entries to fix stack depot warnings

2024-12-09T09:41:03Z

commit 45c9f2b856a075a34873d00788d2e8a250c1effd upstream. The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing. IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies. Cc: stable@vger.kernel.org # 5.15+ Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

ARM: 9429/1: ioremap: Sync PGDs for VMALLOC shadow

2024-12-09T09:41:03Z

commit d6e6a74d4cea853b5321eeabb69c611148eedefe upstream. When sync:ing the VMALLOC area to other CPUs, make sure to also sync the KASAN shadow memory for the VMALLOC area, so that we don't get stale entries for the shadow memory in the top level PGD. Since we are now copying PGDs in two instances, create a helper function named memcpy_pgd() to do the actual copying, and create a helper to map the addresses of VMALLOC_START and VMALLOC_END into the corresponding shadow memory. Co-developed-by: Melon Liu Cc: stable@vger.kernel.org Fixes: 565cbaad83d8 ("ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC") Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/ Reported-by: Clement LE GOFFIC Suggested-by: Mark Rutland Suggested-by: Russell King (Oracle) Acked-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang

2024-12-09T09:41:02Z

commit d677ce521334d8f1f327cafc8b1b7854b0833158 upstream. Under certain conditions, the 64-bit '-mstack-protector-guard' flags may end up in the 32-bit vDSO flags, resulting in build failures due to the structure of clang's argument parsing of the stack protector options, which validates the arguments of the stack protector guard flags unconditionally in the frontend, choking on the 64-bit values when targeting 32-bit: clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2 clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2 make[3]: *** [arch/powerpc/kernel/vdso/Makefile:85: arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1 make[3]: *** [arch/powerpc/kernel/vdso/Makefile:87: arch/powerpc/kernel/vdso/vgetrandom-32.o] Error 1 Remove these flags by adding them to the CC32FLAGSREMOVE variable, which already handles situations similar to this. Additionally, reformat and align a comment better for the expanding CONFIG_CC_IS_CLANG block. Cc: stable@vger.kernel.org # v6.1+ Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241030-powerpc-vdso-drop-stackp-flags-clang-v1-1-d95e7376d29c@kernel.org Signed-off-by: Greg Kroah-Hartman

arm64: dts: freescale: imx8mp-verdin: Fix SD regulator startup delay

2024-12-09T09:40:58Z

commit 6c5789c9d2c06968532243daa235f6ff809ad71e upstream. The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman

arm64: dts: mediatek: mt8186-corsola: Fix IT6505 reset line polarity

2024-12-09T09:40:57Z

commit fbcc95fceb6d179dd150df2dc613dfd9b013052c upstream. The reset line of the IT6505 bridge chip is active low, not active high. It was incorrectly inverted in the device tree as the implementation at the time incorrectly inverted the polarity in its driver, due to a prior device having an inline inverting level shifter. Fix the polarity now while the external display pipeline is incomplete, thereby avoiding any impact to running systems. A matching fix for the driver should be included if this change is backported. Fixes: 8855d01fb81f ("arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool") Cc: stable@vger.kernel.org Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20241029100226.660263-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Greg Kroah-Hartman