summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2 dayss390/hypfs: Enable limited access during lockdownPeter Oberparleiter1-1/+2
[ Upstream commit 3868f910440c47cd5d158776be4ba4e2186beda7 ] When kernel lockdown is active, debugfs_locked_down() blocks access to hypfs files that register ioctl callbacks, even if the ioctl interface is not required for a function. This unnecessarily breaks userspace tools that only rely on read operations. Resolve this by registering a minimal set of file operations during lockdown, avoiding ioctl registration and preserving access for affected tooling. Note that this change restores hypfs functionality when lockdown is active from early boot (e.g. via lockdown=integrity kernel parameter), but does not apply to scenarios where lockdown is enabled dynamically while Linux is running. Tested-by: Mete Durlu <meted@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2 dayss390/hypfs: Avoid unnecessary ioctl registration in debugfsPeter Oberparleiter1-7/+11
[ Upstream commit fec7bdfe7f8694a0c39e6c3ec026ff61ca1058b9 ] Currently, hypfs registers ioctl callbacks for all debugfs files, despite only one file requiring them. This leads to unintended exposure of unused interfaces to user space and can trigger side effects such as restricted access when kernel lockdown is enabled. Restrict ioctl registration to only those files that implement ioctl functionality to avoid interface clutter and unnecessary access restrictions. Tested-by: Mete Durlu <meted@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2 dayss390/mm: Do not map lowcore with identity mappingHeiko Carstens1-0/+3
[ Upstream commit 93f616ff870a1fb7e84d472cad0af651b18f9f87 ] Since the identity mapping is pinned to address zero the lowcore is always also mapped to address zero, this happens regardless of the relocate_lowcore command line option. If the option is specified the lowcore is mapped twice, instead of only once. This means that NULL pointer accesses will succeed instead of causing an exception (low address protection still applies, but covers only parts). To fix this never map the first two pages of physical memory with the identity mapping. Fixes: 32db401965f1 ("s390/mm: Pin identity mapping base to zero") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2 daysLoongArch: Optimize module load time by optimizing PLT/GOT countingKanglong Wang1-18/+18
[ Upstream commit 63dbd8fb2af3a89466538599a9acb2d11ef65c06 ] When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows: rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158 After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock. When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity. To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations. After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace". Using the default configuration to test some modules, the results are as follows: Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098 With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098 Fixes: fcdfe9d22bed ("LoongArch: Add ELF and module support") Signed-off-by: Kanglong Wang <wangkanglong@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
2 daysx86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helperTianxiang Peng1-0/+3
commit d8df126349dad855cdfedd6bbf315bad2e901c2f upstream. Since 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ] Fixes: 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") Signed-off-by: Tianxiang Peng <txpeng@tencent.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Hui Li <caelli@tencent.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/20250623093153.3016937-1-txpeng@tencent.com Signed-off-by: Tianxiang Peng <txpeng@tencent.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 dayspowerpc/boot: Fix build with gcc 15Michal Suchanek1-0/+1
commit 5a821e2d69e26b51b7f3740b6b0c3462b8cacaff upstream. Similar to x86 the ppc boot code does not build with GCC 15. Copy the fix from commit ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15") Signed-off-by: Michal Suchanek <msuchanek@suse.de> Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250331105722.19709-1-msuchanek@suse.de Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 dayscompiler: remove __ADDRESSABLE_ASM{_STR,}() againJan Beulich1-2/+3
[ Upstream commit 8ea815399c3fcce1889bd951fec25b5b9a3979c1 ] __ADDRESSABLE_ASM_STR() is where the necessary stringification happens. As long as "sym" doesn't contain any odd characters, no quoting is required for its use with .quad / .long. In fact the quotation gets in the way with gas 2.25; it's only from 2.26 onwards that quoted symbols are half-way properly supported. However, assembly being different from C anyway, drop __ADDRESSABLE_ASM_STR() and its helper macro altogether. A simple .global directive will suffice to get the symbol "declared", i.e. into the symbol table. While there also stop open-coding STATIC_CALL_TRAMP() and STATIC_CALL_KEY(). Fixes: 0ef8047b737d ("x86/static-call: provide a way to do very early static-call updates") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <609d2c74-de13-4fae-ab1a-1ec44afb948d@suse.com> [ Adjust context ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board fileJudith Mendez3-24/+48
[ Upstream commit a0b8da04153eb61cc2eaeeea5cc404e91e557f6b ] This moves pinmux child nodes for sdhci0 node from k3-am62x-sk-common to each top level board file. This is needed since we require internal pullups for AM62x SK and not for AM62 LP SK since it has external pullups on DATA 1-7. Internal pulls are required for AM62 SK as per JESD84 spec recommendation to prevent unconnected lines floating. Fixes: d19a66ae488a ("arm64: dts: ti: k3-am625-sk: Enable on board peripherals") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250707190830.3951619-1-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am6*: Remove disable-wp for eMMCJudith Mendez10-10/+0
[ Upstream commit ef839ba8142f14513ba396a033110526b7008096 ] Remove disable-wp flag for eMMC nodes since this flag is only applicable to SD according to the binding doc (mmc/mmc-controller-common.yaml). For eMMC, this flag should be ignored but lets remove anyways to cleanup sdhci nodes. Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://lore.kernel.org/r/20250429151454.4160506-4-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com> Stable-dep-of: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am62*: Add non-removable flag for eMMCJudith Mendez3-0/+3
[ Upstream commit d16e7d34352c4107a81888e9aab4ea4748076e70 ] EMMC device is non-removable so add 'non-removable' DT property to avoid having to redetect the eMMC after suspend/resume. Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20250429151454.4160506-3-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com> Stable-dep-of: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am6*: Add boot phase flag to support MMC bootJudith Mendez2-0/+14
[ Upstream commit db3cd905b8c8cd40f15a34e30a225704bb8a2fcb ] The bootph-all flag was introduced in dt-schema (dtschema/schemas/bootph.yaml) to define node usage across different boot phases. For eMMC and SD boot modes, voltage regulator nodes, io-expander nodes, gpio nodes, and MMC nodes need to be present in all boot stages, so add missing bootph-all phase flag to these nodes to support SD boot and eMMC boot. Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://lore.kernel.org/r/20250429151454.4160506-2-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com> Stable-dep-of: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 dayskvm: retry nx_huge_page_recovery_thread creationKeith Busch1-6/+4
commit 916b7f42b3b3b539a71c204a9b49fdc4ca92cd82 upstream. A VMM may send a non-fatal signal to its threads, including vCPU tasks, at any time, and thus may signal vCPU tasks during KVM_RUN. If a vCPU task receives the signal while its trying to spawn the huge page recovery vhost task, then KVM_RUN will fail due to copy_process() returning -ERESTARTNOINTR. Rework call_once() to mark the call complete if and only if the called function succeeds, and plumb the function's true error code back to the call_once() invoker. This provides userspace with the correct, non-fatal error code so that the VMM doesn't terminate the VM on -ENOMEM, and allows subsequent KVM_RUN a succeed by virtue of retrying creation of the NX huge page task. Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> [implemented the kvm user side] Signed-off-by: Keith Busch <kbusch@kernel.org> Message-ID: <20250227230631.303431-3-kbusch@meta.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Alistair Delva <adelva@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysx86/sev: Ensure SVSM reserved fields in a page validation entry are ↵Tom Lendacky1-0/+3
initialized to zero commit 3ee9cebd0a5e7ea47eb35cec95eaa1a866af982d upstream. In order to support future versions of the SVSM_CORE_PVALIDATE call, all reserved fields within a PVALIDATE entry must be set to zero as an SVSM should be ensuring all reserved fields are zero in order to support future usage of reserved areas based on the protocol version. Fixes: fcd042e86422 ("x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Joerg Roedel <joerg.roedel@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/7cde412f8b057ea13a646fb166b1ca023f6a5031.1755098819.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysLoongArch: KVM: Make function kvm_own_lbt() robustBibo Mao1-3/+5
commit 4be8cefc132606b4a6e851f37f8e8c40c406c910 upstream. Add the flag KVM_LARCH_LBT checking in function kvm_own_lbt(), so that it can be called safely rather than duplicated enabling again. Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Update comments in make_insert_tlbJohn David Anglin1-5/+12
commit cb22f247f371bd206a88cf0e0c05d80b8b62fb26 upstream. The following testcase exposed a problem with our read access checks in get_user() and raw_copy_from_user(): #include <stdint.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <sys/types.h> int main(int argc, char **argv) { unsigned long page_size = sysconf(_SC_PAGESIZE); char *p = malloc(3 * page_size); char *p_aligned; /* initialize memory region. If not initialized, write syscall below will correctly return EFAULT. */ if (1) memset(p, 'X', 3 * page_size); p_aligned = (char *) ((((uintptr_t) p) + (2*page_size - 1)) & ~(page_size - 1)); /* Drop PROT_READ protection. Kernel and userspace should fault when accessing that memory region */ mprotect(p_aligned, page_size, PROT_NONE); /* the following write() should return EFAULT, since PROT_READ was dropped by previous mprotect() */ int ret = write(2, p_aligned, 1); if (!ret || errno != EFAULT) printf("\n FAILURE: write() did not returned expected EFAULT value\n"); return 0; } Because of the way _PAGE_READ is handled, kernel code never generates a read access fault when it access a page as the kernel privilege level is always less than PL1 in the PTE. This patch reworks the comments in the make_insert_tlb macro to try to make this clearer. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Try to fixup kernel exception in bad_area_nosemaphore path of ↵John David Anglin1-0/+4
do_page_fault() commit f92a5e36b0c45cd12ac0d1bc44680c0dfae34543 upstream. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Revise gateway LWS calls to probe user read accessJohn David Anglin1-9/+21
commit f6334f4ae9a4e962ba74b026e1d965dfdf8cbef8 upstream. We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER). Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Revise __get_user() to probe user read accessJohn David Anglin1-3/+18
commit 89f686a0fb6e473a876a9a60a13aec67a62b9a7e upstream. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Rename pte_needs_flush() to pte_needs_cache_flush() in cache.cJohn David Anglin1-2/+2
commit 52ce9406a9625c4498c4eaa51e7a7ed9dcb9db16 upstream. The local name used in cache.c conflicts the declaration in include/asm-generic/tlb.h. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Makefile: explain that 64BIT requires both 32-bit and 64-bit compilersRandy Dunlap1-1/+3
commit 305ab0a748c52eeaeb01d8cff6408842d19e5cb5 upstream. For building a 64-bit kernel, both 32-bit and 64-bit VDSO binaries are built, so both 32-bit and 64-bit compilers (and tools) should be in the PATH environment variable. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Drop WARN_ON_ONCE() from flush_cache_vmapJohn David Anglin1-1/+1
commit 4eab1c27ce1f0e89ab67b01bf1e4e4c75215708a upstream. I have observed warning to occassionally trigger. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Define and use set_pte_at()John David Anglin1-3/+4
commit 802e55488bc2cc1ab6423b720255a785ccac42ce upstream. When a PTE is changed, we need to flush the PTE. set_pte_at() was lost in the folio update. PA-RISC version is the same as the generic version. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysparisc: Check region is readable by user in raw_copy_from_user()John David Anglin2-1/+46
commit 91428ca9320edbab1211851d82429d33b9cd73ef upstream. Because of the way the _PAGE_READ is handled in the parisc PTE, an access interruption is not generated when the kernel reads from a region where the _PAGE_READ is zero. The current code was written assuming read access faults would also occur in the kernel. This change adds user access checks to raw_copy_from_user(). The prober_user() define checks whether user code has read access to a virtual address. Note that page faults are not handled in the exception support for the probe instruction. For this reason, we precede the probe by a ldb access check. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am62-verdin: Enable pull-ups on I2C busesEmanuele Ghidoli1-6/+6
commit bdf4252f736cc1d2a8e3e633c70fe6c728f0756e upstream. Enable internal bias pull-ups on the SoC-side I2C buses that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Cc: stable@vger.kernel.org Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250528110741.262336-1-ghidoliemanuele@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am62a7-sk: fix pinmux for main_uart1Hong Guan1-2/+2
commit 8e44ac61abaae56fc6eb537a04ed78b458c5b984 upstream. main_uart1 reserved for TIFS firmware traces is routed to the onboard FT4232 via a FET switch which is connected to pin A21 and B21 of the SoC and not E17 and C17. Fix it. Fixes: cf39ff15cc01a ("arm64: dts: ti: k3-am62a7-sk: Describe main_uart1 and wkup_uart") Cc: stable@vger.kernel.org Signed-off-by: Hong Guan <hguan@ti.com> [bb@ti.com: expanded commit message] Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20250707-uart-fixes-v1-1-8164147218b0@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: exynos: gs101: ufs: add dma-coherent propertyPeter Griffin1-0/+1
commit 4292564c71cffd8094abcc52dd4840870d05cd30 upstream. ufs-exynos driver configures the sysreg shareability as cacheable for gs101 so we need to set the dma-coherent property so the descriptors are also allocated cacheable. This fixes the UFS stability issues we have seen with the upstream UFS driver on gs101. Fixes: 4c65d7054b4c ("arm64: dts: exynos: gs101: Add ufs and ufs-phy dt nodes") Cc: stable@vger.kernel.org Suggested-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Will McVicker <willmcvicker@google.com> Tested-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250314-ufs-dma-coherent-v1-1-bdf9f9be2919@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by defaultAlexander Sverdlin1-3/+12
commit 5b272127884bded21576a6ddceca13725a351c63 upstream. Switch Schmitt Trigger functions for PIN_INPUT* macros by default. This is HW PoR configuration, the slew rate requirements without ST enabled are pretty tough for these devices. We've noticed spurious GPIO interrupts even with noise-free edges but not meeting slew rate requirements (3.3E+6 V/s for 3.3v LVCMOS). It's not obvious why one might want to disable the PoR-enabled ST on any pin. Just enable it by default. As it's not possible to provide OR-able macros to disable the ST, shall anyone require it, provide a set of new macros with _NOST suffix. Fixes: fe49f2d776f7 ("arm64: dts: ti: Use local header for pinctrl register values") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20250701105437.3539924-1-alexander.sverdlin@siemens.com [vigneshr@ti.com: Add Fixes tag] Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysarm64: dts: ti: k3-am62-main: Remove eMMC High Speed DDR supportJudith Mendez1-1/+0
commit 265f70af805f33a0dfc90f50cc0f116f702c3811 upstream. For eMMC, High Speed DDR mode is not supported [0], so remove mmc-ddr-1_8v flag which adds the capability. [0] https://www.ti.com/lit/gpn/am625 Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250707191250.3953990-1-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 dayslib/crypto: mips/chacha: Fix clang build and remove unneeded byteswapEric Biggers1-13/+7
commit 22375adaa0d9fbba9646c8e2b099c6e87c97bfae upstream. The MIPS32r2 ChaCha code has never been buildable with the clang assembler. First, clang doesn't support the 'rotl' pseudo-instruction: error: unknown instruction, did you mean: rol, rotr? Second, clang requires that both operands of the 'wsbh' instruction be explicitly given: error: too few operands for instruction To fix this, align the code with the real instruction set by (1) using the real instruction 'rotr' instead of the nonstandard pseudo- instruction 'rotl', and (2) explicitly giving both operands to 'wsbh'. To make removing the use of 'rotl' a bit easier, also remove the unnecessary special-casing for big endian CPUs at .Lchacha_mips_xor_bytes. The tail handling is actually endian-independent since it processes one byte at a time. On big endian CPUs the old code byte-swapped SAVED_X, then iterated through it in reverse order. But the byteswap and reverse iteration canceled out. Tested with chacha20poly1305-selftest in QEMU using "-M malta" with both little endian and big endian mips32r2 kernels. Fixes: 49aa7c00eddf ("crypto: mips/chacha - import 32r2 ChaCha code from Zinc") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505080409.EujEBwA0-lkp@intel.com/ Link: https://lore.kernel.org/r/20250619225535.679301-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2 daysm68k: Fix lost column on framebuffer debug consoleFinn Thain1-10/+21
commit 210a1ce8ed4391b64a888b3fb4b5611a13f5ccc7 upstream. Move the cursor position rightward after rendering the character, not before. This avoids complications that arise when the recursive console_putc call has to wrap the line and/or scroll the display. This also fixes the linewrap bug that crops off the rightmost column. When the cursor is at the bottom of the display, a linefeed will not move the cursor position further downward. Instead, the display scrolls upward. Avoid the repeated add/subtract sequence by way of a single subtraction at the initialization of console_struct_num_rows. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Finn Thain <fthain@linux-m68k.org> Tested-by: Stan Johnson <userm57@yahoo.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/9d4e8c68a456d5f2bc254ac6f87a472d066ebd5e.1743115195.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysarm64: dts: ti: k3-j722s-evm: Fix USB gpio-hog level for Type-CSiddharth Vadapalli1-1/+1
[ Upstream commit 65ba2a6e77e9e5c843a591055789050e77b5c65e ] According to the "GPIO Expander Map / Table" section of the J722S EVM Schematic within the Evaluation Module Design Files package [0], the GPIO Pin P05 located on the GPIO Expander 1 (I2C0/0x23) has to be pulled down to select the Type-C interface. Since commit under Fixes claims to enable the Type-C interface, update the property within "p05-hog" from "output-high" to "output-low", thereby switching from the Type-A interface to the Type-C interface. [0]: https://www.ti.com/lit/zip/sprr495 Cc: stable@vger.kernel.org Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250623100657.4082031-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysarm64: dts: ti: k3-j722s-evm: Fix USB2.0_MUX_SEL to select Type-CHrushikesh Salunke1-1/+1
[ Upstream commit bc8d9e6b5821c40ab5dd3a81e096cb114939de50 ] J722S SOC has two usb controllers USB0 and USB1. USB0 is brought out on the EVM as a stacked USB connector which has one Type-A and one Type-C port. These Type-A and Type-C ports are connected to MUX so only one of them can be enabled at a time. Commit under Fixes, tries to enable the USB0 instance of USB to interface with the Type-C port via the USB hub, by configuring the USB2.0_MUX_SEL to GPIO_ACTIVE_HIGH. But it is observed on J722S-EVM that Type-A port is enabled instead of Type-C port. Fix this by setting USB2.0_MUX_SEL to GPIO_ACTIVE_LOW to enable Type-C port. Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20250116125726.2549489-1-h-salunke@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Stable-dep-of: 65ba2a6e77e9 ("arm64: dts: ti: k3-j722s-evm: Fix USB gpio-hog level for Type-C") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysmm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Anshuman Khandual3-8/+0
commit 59305202c67fea50378dcad0cc199dbc13a0e99a upstream. Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Dev Jain <dev.jain@arm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> [s390] Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysparisc: Makefile: fix a typo in palo.confRandy Dunlap1-1/+1
commit 963f1b20a8d2a098954606b9725cd54336a2a86c upstream. Correct "objree" to "objtree". "objree" is not defined. Fixes: 75dd47472b92 ("kbuild: remove src and obj from the top Makefile") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysMIPS: lantiq: falcon: sysctrl: fix request memory check logicShiji Yang1-13/+10
[ Upstream commit 9c9a7ff9882fc6ba7d2f4050697e8bb80383e8dc ] request_mem_region() will return NULL instead of error code when the memory request fails. Therefore, we should check if the return value is non-zero instead of less than zero. In this way, this patch also fixes the build warnings: arch/mips/lantiq/falcon/sysctrl.c:214:50: error: ordered comparison of pointer with integer zero [-Werror=extra] 214 | res_status.name) < 0) || | ^ arch/mips/lantiq/falcon/sysctrl.c:216:47: error: ordered comparison of pointer with integer zero [-Werror=extra] 216 | res_ebu.name) < 0) || | ^ arch/mips/lantiq/falcon/sysctrl.c:219:50: error: ordered comparison of pointer with integer zero [-Werror=extra] 219 | res_sys[0].name) < 0) || | ^ arch/mips/lantiq/falcon/sysctrl.c:222:50: error: ordered comparison of pointer with integer zero [-Werror=extra] 222 | res_sys[1].name) < 0) || | ^ arch/mips/lantiq/falcon/sysctrl.c:225:50: error: ordered comparison of pointer with integer zero [-Werror=extra] 225 | res_sys[2].name) < 0)) | Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysMIPS: Don't crash in stack_top() for tasks without ABI or vDSOThomas Weißschuh1-7/+9
[ Upstream commit e9f4a6b3421e936c3ee9d74710243897d74dbaa2 ] Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash. This can for example happen when using kunit: mips_stack_top+0x28/0xc0 arch_pick_mmap_layout+0x190/0x220 kunit_vm_mmap_init+0xf8/0x138 __kunit_add_resource+0x40/0xa8 kunit_vm_mmap+0x88/0xd8 usercopy_test_init+0xb8/0x240 kunit_try_run_case+0x5c/0x1a8 kunit_generic_run_threadfn_adapter+0x28/0x50 kthread+0x118/0x240 ret_from_kernel_thread+0x14/0x1c Only dereference the ABI point if it is set. The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysMIPS: vpe-mt: add missing prototypes for vpe_{alloc,start,stop,free}Shiji Yang1-0/+8
[ Upstream commit 844615dd0f2d95c018ec66b943e08af22b62aff3 ] These functions are exported but their prototypes are not defined. This patch adds the missing function prototypes to fix the following compilation warnings: arch/mips/kernel/vpe-mt.c:180:7: error: no previous prototype for 'vpe_alloc' [-Werror=missing-prototypes] 180 | void *vpe_alloc(void) | ^~~~~~~~~ arch/mips/kernel/vpe-mt.c:198:5: error: no previous prototype for 'vpe_start' [-Werror=missing-prototypes] 198 | int vpe_start(void *vpe, unsigned long start) | ^~~~~~~~~ arch/mips/kernel/vpe-mt.c:208:5: error: no previous prototype for 'vpe_stop' [-Werror=missing-prototypes] 208 | int vpe_stop(void *vpe) | ^~~~~~~~ arch/mips/kernel/vpe-mt.c:229:5: error: no previous prototype for 'vpe_free' [-Werror=missing-prototypes] 229 | int vpe_free(void *vpe) | ^~~~~~~~ Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysarm64: stacktrace: Check kretprobe_find_ret_addr() return valueMark Rutland1-0/+2
[ Upstream commit beecfd6a88a675e20987e70ec532ba734b230fa4 ] If kretprobe_find_ret_addr() fails to find the original return address, it returns 0. Check for this case so that a reliable stacktrace won't silently ignore it. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andrea della Porta <andrea.porta@suse.com> Cc: Breno Leitao <leitao@debian.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Petr Mladek <pmladek@suse.com> Cc: Song Liu <song@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-and-tested-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20250521111000.2237470-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 dayspowerpc: floppy: Add missing checks after DMA mapThomas Fourier1-1/+4
[ Upstream commit cf183c1730f2634245da35e9b5d53381b787d112 ] The DMA map functions can fail and should be tested for errors. Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250620075602.12575-1-fourier.thomas@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysACPI: Suppress misleading SPCR console message when SPCR table is absentLi Chen1-3/+7
[ Upstream commit bad3fa2fb9206f4dcec6ddef094ec2fbf6e8dcb2 ] The kernel currently alway prints: "Use ACPI SPCR as default console: No/Yes " even on systems that lack an SPCR table. This can mislead users into thinking the SPCR table exists on the machines without SPCR. With this change, the "Yes" is only printed if the SPCR table is present, parsed and !param_acpi_nospcr. This avoids user confusion on SPCR-less systems. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20250620131309.126555-3-me@linux.beauty Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 days(powerpc/512) Fix possible `dma_unmap_single()` on uninitialized pointerThomas Fourier1-4/+2
[ Upstream commit 760b9b4f6de9a33ca56a05f950cabe82138d25bd ] If the device configuration fails (if `dma_dev->device_config()`), `sg_dma_address(&sg)` is not initialized and the jump to `err_dma_prep` leads to calling `dma_unmap_single()` on `sg_dma_address(&sg)`. Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250610142918.169540-2-fourier.thomas@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
10 dayss390/early: Copy last breaking event address to pt_regsHeiko Carstens1-0/+1
[ Upstream commit 7cf636c99b257c1b4b12066ab34fd5f06e8d892f ] In case of an early crash the early program check handler also prints the last breaking event address which is contained within the pt_regs structure. However it is not initialized, and therefore a more or less random value is printed in case of a crash. Copy the last breaking event address from lowcore to pt_regs in case of an early program check to address this. This also makes it easier to analyze early crashes. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 dayss390/stp: Remove udelay from stp_sync_clock()Sven Schnelle1-1/+1
[ Upstream commit b367017cdac21781a74eff4e208d3d38e1f38d3f ] When an stp sync check is handled on a system with multiple cpus each cpu gets a machine check but only the first one actually handles the sync operation. All other CPUs spin waiting for the first one to finish with a short udelay(). But udelay can't be used here as the first CPU modifies tod_clock_base before performing the sync op. During this timeframe get_tod_clock_monotonic() might return a non-monotonic time. The time spent waiting should be very short and udelay is a busy loop anyways, therefore simply remove the udelay. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysum: Re-evaluate thread flags repeatedlyThomas Weißschuh2-8/+16
[ Upstream commit b9e2f2246eb2b5617d53af7b5e4e1b8c916f26a8 ] The thread flags may change during their processing. For example a task_work can queue a new signal to be sent. This signal should be delivered before returning to usespace again. Evaluate the flags repeatedly similar to other architectures. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20250704-uml-thread_flags-v1-1-0e293fd8d627@linutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysarm64: Mark kernel as tainted on SAE and SError panicBreno Leitao2-0/+2
[ Upstream commit d7ce7e3a84642aadf7c4787f7ec4f58eb163d129 ] Set TAINT_MACHINE_CHECK when SError or Synchronous External Abort (SEA) interrupts trigger a panic to flag potential hardware faults. This tainting mechanism aids in debugging and enables correlation of hardware-related crashes in large-scale deployments. This change aligns with similar patches[1] that mark machine check events when the system crashes due to hardware errors. Link: https://lore.kernel.org/all/20250702-add_tain-v1-1-9187b10914b9@debian.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250716-vmcore_hw_error-v2-1-f187f7d62aba@debian.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 dayss390/time: Use monotonic clock in get_cycles()Sven Schnelle1-7/+6
[ Upstream commit 09e7e29d2b49ba84bcefb3dc1657726d2de5bb24 ] Otherwise the code might not work correctly when the clock is changed. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysx86/bugs: Avoid warning when overriding return thunkPawan Gupta1-3/+2
[ Upstream commit 9f85fdb9fc5a1bd308a10a0a7d7e34f2712ba58b ] The purpose of the warning is to prevent an unexpected change to the return thunk mitigation. However, there are legitimate cases where the return thunk is intentionally set more than once. For example, ITS and SRSO both can set the return thunk after retbleed has set it. In both the cases retbleed is still mitigated. Replace the warning with an info about the active return thunk. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250611-eibrs-fix-v4-3-5ff86cac6c61@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysARM: tegra: Use I/O memcpy to write to IRAMAaron Kling1-1/+1
[ Upstream commit 398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1 ] Kasan crashes the kernel trying to check boundaries when using the normal memcpy. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250522-mach-tegra-kasan-v1-1-419041b8addb@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysARM: rockchip: fix kernel hang during smp initializationAlexander Kochetkov1-6/+9
[ Upstream commit 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 ] In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysarm64: Handle KCOV __init vs inline mismatchesKees Cook1-1/+1
[ Upstream commit 65c430906efffee9bd7551d474f01a6b1197df90 ] GCC appears to have kind of fragile inlining heuristics, in the sense that it can change whether or not it inlines something based on optimizations. It looks like the kcov instrumentation being added (or in this case, removed) from a function changes the optimization results, and some functions marked "inline" are _not_ inlined. In that case, we end up with __init code calling a function not marked __init, and we get the build warnings I'm trying to eliminate in the coming patch that adds __no_sanitize_coverage to __init functions: WARNING: modpost: vmlinux: section mismatch in reference: acpi_get_enable_method+0x1c (section: .text.unlikely) -> acpi_psci_present (section: .init.text) This problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it), but we've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on. For arm64 this requires forcing one ACPI function to be inlined with __always_inline. Link: https://lore.kernel.org/r/20250724055029.3623499-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>