April 2024 - Linux-stable-mirror

[tip: x86/urgent] cpu: Re-enable CPU mitigations by default for !X86 architectures

by tip-bot2 for Sean Christopherson

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: fe42754b94a42d08cf9501790afc25c4f6a5f631 Gitweb: https://git.kernel.org/tip/fe42754b94a42d08cf9501790afc25c4f6a5f631 Author: Sean Christopherson <seanjc(a)google.com> AuthorDate: Fri, 19 Apr 2024 17:05:54 -07:00 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Thu, 25 Apr 2024 15:47:35 +02:00 cpu: Re-enable CPU mitigations by default for !X86 architectures Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution. Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time. Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Reported-by: Michael Ellerman <mpe(a)ellerman.id.au> Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Josh Poimboeuf <jpoimboe(a)kernel.org> Acked-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com --- arch/Kconfig | 8 ++++++++ arch/x86/Kconfig | 11 ++++++----- kernel/cpu.c | 4 ++-- 3 files changed, 16 insertions(+), 7 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 65afb1d..30f7930 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -9,6 +9,14 @@ # source "arch/$(SRCARCH)/Kconfig" +config ARCH_CONFIGURES_CPU_MITIGATIONS + bool + +if !ARCH_CONFIGURES_CPU_MITIGATIONS +config CPU_MITIGATIONS + def_bool y +endif + menu "General architecture-dependent options" config ARCH_HAS_SUBPAGE_FAULTS diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 4474bf3..619a04d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -62,6 +62,7 @@ config X86 select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU select ARCH_32BIT_OFF_T if X86_32 select ARCH_CLOCKSOURCE_INIT + select ARCH_CONFIGURES_CPU_MITIGATIONS select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 @@ -2488,17 +2489,17 @@ config PREFIX_SYMBOLS def_bool y depends on CALL_PADDING && !CFI_CLANG -menuconfig SPECULATION_MITIGATIONS - bool "Mitigations for speculative execution vulnerabilities" +menuconfig CPU_MITIGATIONS + bool "Mitigations for CPU vulnerabilities" default y help - Say Y here to enable options which enable mitigations for - speculative execution hardware vulnerabilities. + Say Y here to enable options which enable mitigations for hardware + vulnerabilities (usually related to speculative execution). If you say N, all mitigations will be disabled. You really should know what you are doing to say so. -if SPECULATION_MITIGATIONS +if CPU_MITIGATIONS config MITIGATION_PAGE_TABLE_ISOLATION bool "Remove the kernel mapping in user mode" diff --git a/kernel/cpu.c b/kernel/cpu.c index 07ad53b..bb0ff27 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -3207,8 +3207,8 @@ enum cpu_mitigations { }; static enum cpu_mitigations cpu_mitigations __ro_after_init = - IS_ENABLED(CONFIG_SPECULATION_MITIGATIONS) ? CPU_MITIGATIONS_AUTO : - CPU_MITIGATIONS_OFF; + IS_ENABLED(CONFIG_CPU_MITIGATIONS) ? CPU_MITIGATIONS_AUTO : + CPU_MITIGATIONS_OFF; static int __init mitigations_parse_cmdline(char *arg) {

1 year, 5 months

1
0
0 0

[PATCH] kbuild: rust: force `alloc` extern to allow "empty" Rust files

by Miguel Ojeda

If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida(a)collabora.com> Reported-by: Julian Stecklina <julian.stecklina(a)cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/… [1] Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Link: https://github.com/rust-lang/rust/issues/111302 [2] Link: https://github.com/rust-lang/rust/pull/109421 [3] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index baf86c0880b6..533a7799fdfe 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -273,7 +273,7 @@ rust_common_cmd = \ -Zallow-features=$(rust_allowed_features) \ -Zcrate-attr=no_std \ -Zcrate-attr='feature($(rust_allowed_features))' \ - --extern alloc --extern kernel \ + -Zunstable-options --extern force:alloc --extern kernel \ --crate-type rlib -L $(objtree)/rust/ \ --crate-name $(basename $(notdir $@)) \ --sysroot=/dev/null \ base-commit: 4cece764965020c22cff7665b18a012006359095 -- 2.44.0

1 year, 5 months

4
3
0 0

[PATCH 0/3] HID: bpf: some fixes for pre-loading HID-BPF

by Benjamin Tissoires

As I am working on the next functionalities of HID-BPF, I realized that I had a few issues while preloading the skeleton at boot. None of the errors are terrible as they are not inducing a kernel crash, so it's not super urgent IMO. Regarding the last one, I'm not sure what makes RHEL behave slightly different than upstream. But I am not sure also that the code matches upstream everywhere, so lazy loading it seems like a sensible idea. Furthermore, that also means that the code will not be available until requested by user space, which fits well in the whole idea of HID-BPF: if the user doesn't want it, then it shouldn't be it. Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> --- Benjamin Tissoires (3): HID: bpf: fix a comment in a define HID: bpf: fix return value of entrypoints_*__attach() HID: bpf: lazy load the hid_tail_call entrypoint drivers/hid/bpf/hid_bpf_dispatch.c | 6 ------ drivers/hid/bpf/hid_bpf_jmp_table.c | 17 ++++++++++++----- 2 files changed, 12 insertions(+), 11 deletions(-) --- base-commit: b912cf042072e12e93faa874265b30cc0aa521b9 change-id: 20240419-hid_bpf_lazy_skel-ab0d674cb49b Best regards, -- Benjamin Tissoires <bentiss(a)kernel.org>

1 year, 5 months

2
6
0 0

[tip: irq/urgent] irqchip/gic-v3-its: Prevent double free on error

by tip-bot2 for Guanrui Huang

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: c26591afd33adce296c022e3480dea4282b7ef91 Gitweb: https://git.kernel.org/tip/c26591afd33adce296c022e3480dea4282b7ef91 Author: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> AuthorDate: Thu, 18 Apr 2024 14:10:52 +08:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Thu, 25 Apr 2024 14:30:46 +02:00 irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibab… --- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a537cb..5f7d3db 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -4567,13 +4567,8 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq irqd_set_resend_when_in_progress(irq_get_irq_data(virq + i)); } - if (err) { - if (i > 0) - its_vpe_irq_domain_free(domain, virq, i); - - its_lpi_free(bitmap, base, nr_ids); - its_free_prop_table(vprop_page); - } + if (err) + its_vpe_irq_domain_free(domain, virq, i); return err; }

1 year, 5 months

1
0
0 0

stable-rc: 5.10: arm64: ring_buffer.c:1479:21: error: implicit declaration of function 'try_cmpxchg'

by Naresh Kamboju

The arm64 and arm builds are failing on stable-rc linux.5.10.y branch due to following build warnings / errors. Anders, build bisected and found first commit as, first bad commit: [9bf29b51d2bc21abdb8bd36382c1c324a1c54ca7] ring-buffer: Only update pages_touched when a new page is touched Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Build log: ----- kernel/trace/ring_buffer.c: In function 'rb_tail_page_update': kernel/trace/ring_buffer.c:1479:21: error: implicit declaration of function 'try_cmpxchg'; did you mean 'xa_cmpxchg'? [-Werror=implicit-function-declaration] 1479 | if (try_cmpxchg(&cpu_buffer->tail_page, &tail_page, next_page)) | ^~~~~~~~~~~ | xa_cmpxchg cc1: some warnings being treated as errors Links: - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFu97bCGW3ZYMbPsIp… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFuBOMDouq6VfImqR2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10… Meta data: git_repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc git_sha : 5feded50ee597a37f4778545a879337c2f72490d git_short_log : 5feded50ee59 ("Linux 5.10.216-rc1") arch: arm64 toolchain: gcc-12 Steps to reproduce: --- - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFuBOMDouq6VfImqR2… -- Linaro LKFT https://lkft.linaro.org

1 year, 5 months

1
0
0 0

[PATCH -next] fbdev: savage: Handle err return when savagefb_check_var failed

by Cai Xinchen

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. Fixes: 04e5eac8f3ab ("fbdev: savage: Error out if pixclock equals zero") Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> Cc: stable(a)vger.kernel.org --- drivers/video/fbdev/savage/savagefb_driver.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c index ebc9aeffdde7..ac41f8f37589 100644 --- a/drivers/video/fbdev/savage/savagefb_driver.c +++ b/drivers/video/fbdev/savage/savagefb_driver.c @@ -2276,7 +2276,10 @@ static int savagefb_probe(struct pci_dev *dev, const struct pci_device_id *id) if (info->var.xres_virtual > 0x1000) info->var.xres_virtual = 0x1000; #endif - savagefb_check_var(&info->var, info); + err = savagefb_check_var(&info->var, info); + if (err) + goto failed; + savagefb_set_fix(info); /* -- 2.34.1

1 year, 5 months

2
1
0 0

[PATCH v1] usb: typec: tcpm: clear pd_event queue in PORT_RESET

by RD Babiera

When a Fast Role Swap control message attempt results in a transition to ERROR_RECOVERY, the TCPC can still queue a TCPM_SOURCING_VBUS event. If the event is queued but processed after the tcpm_reset_port() call in the PORT_RESET state, then the following occurs: 1. tcpm_reset_port() calls tcpm_init_vbus() to reset the vbus sourcing and sinking state 2. tcpm_pd_event_handler() turns VBUS on before the port is in the default state. 3. The port resolves as a sink. In the SNK_DISCOVERY state, tcpm_set_charge() cannot set vbus to charge. Clear pd events within PORT_RESET to get rid of non-applicable events. Fixes: b17dd57118fe ("staging: typec: tcpm: Improve role swap with non PD capable partners") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index c26fb70c3ec6..6dcafbaf10a2 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -5605,6 +5605,7 @@ static void run_state_machine(struct tcpm_port *port) break; case PORT_RESET: tcpm_reset_port(port); + port->pd_events = 0; if (port->self_powered) tcpm_set_cc(port, TYPEC_CC_OPEN); else base-commit: 684e9f5f97eb4b7831298ffad140d5c1d426ff27 -- 2.44.0.769.g3c40516874-goog

1 year, 5 months

2
1
0 0

[PATCH v1] usb: typec: tcpm: queue correct sop type in tcpm_queue_vdm_unlocked

by RD Babiera

tcpm_queue_vdm_unlocked queues VDMs over SOP regardless of input parameter tx_sop_type. Fix tcpm_queue_vdm() call. Fixes: 7e7877c55eb1 ("usb: typec: tcpm: add alt mode enter/exit/vdm support for sop'") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- Patch applies starting at 6.9 tree. --- drivers/usb/typec/tcpm/tcpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index c26fb70c3ec6..3f38e7c7d13f 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -1565,7 +1565,7 @@ static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header, const u32 *data, int cnt, enum tcpm_transmit_type tx_sop_type) { mutex_lock(&port->lock); - tcpm_queue_vdm(port, header, data, cnt, TCPC_TX_SOP); + tcpm_queue_vdm(port, header, data, cnt, tx_sop_type); mutex_unlock(&port->lock); } base-commit: 684e9f5f97eb4b7831298ffad140d5c1d426ff27 -- 2.44.0.769.g3c40516874-goog

1 year, 5 months

2
1
0 0

[merged mm-hotfixes-stable] init-fix-allocated-page-overlapping-with-ptr_err.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: init: fix allocated page overlapping with PTR_ERR has been removed from the -mm tree. Its filename was init-fix-allocated-page-overlapping-with-ptr_err.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Nam Cao <namcao(a)linutronix.de> Subject: init: fix allocated page overlapping with PTR_ERR Date: Thu, 18 Apr 2024 12:29:43 +0200 There is nothing preventing kernel memory allocators from allocating a page that overlaps with PTR_ERR(), except for architecture-specific code that setup memblock. It was discovered that RISCV architecture doesn't setup memblock corectly, leading to a page overlapping with PTR_ERR() being allocated, and subsequently crashing the kernel (link in Close: ) The reported crash has nothing to do with PTR_ERR(): the last page (at address 0xfffff000) being allocated leads to an unexpected arithmetic overflow in ext4; but still, this page shouldn't be allocated in the first place. Because PTR_ERR() is an architecture-independent thing, we shouldn't ask every single architecture to set this up. There may be other architectures beside RISCV that have the same problem. Fix this once and for all by reserving the physical memory page that may be mapped to the last virtual memory page as part of low memory. Unfortunately, this means if there is actual memory at this reserved location, that memory will become inaccessible. However, if this page is not reserved, it can only be accessed as high memory, so this doesn't matter if high memory is not supported. Even if high memory is supported, it is still only one page. Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base.are.belong… Link: https://lkml.kernel.org/r/20240418102943.180510-1-namcao@linutronix.de Signed-off-by: Nam Cao <namcao(a)linutronix.de> Reported-by: Bj��rn T��pel <bjorn(a)kernel.org> Tested-by: Bj��rn T��pel <bjorn(a)kernel.org> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Andreas Dilger <adilger(a)dilger.ca> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Changbin Du <changbin.du(a)huawei.com> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Krister Johansen <kjlx(a)templeofstupid.com> Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Tejun Heo <tj(a)kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- init/main.c | 1 + 1 file changed, 1 insertion(+) --- a/init/main.c~init-fix-allocated-page-overlapping-with-ptr_err +++ a/init/main.c @@ -900,6 +900,7 @@ void start_kernel(void) page_address_init(); pr_notice("%s", linux_banner); early_security_init(); + memblock_reserve(__pa(-PAGE_SIZE), PAGE_SIZE); /* reserve last page for ERR_PTR */ setup_arch(&command_line); setup_boot_config(); setup_command_line(command_line); _ Patches currently in -mm which might be from namcao(a)linutronix.de are

1 year, 5 months

2
1
0 0

[merged mm-hotfixes-stable] mm-hugetlb-fix-debug_locks_warn_on1-when-dissolve_free_hugetlb_folio.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() has been removed from the -mm tree. Its filename was mm-hugetlb-fix-debug_locks_warn_on1-when-dissolve_free_hugetlb_folio.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() Date: Fri, 19 Apr 2024 16:58:19 +0800 When I did memory failure tests recently, below warning occurs: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0 Call Trace: <TASK> lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> panic+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> After git bisecting and digging into the code, I believe the root cause is that _deferred_list field of folio is unioned with _hugetlb_subpool field. In __update_and_free_hugetlb_folio(), folio->_deferred_list is initialized leading to corrupted folio->_hugetlb_subpool when folio is hugetlb. Later free_huge_folio() will use _hugetlb_subpool and above warning happens. But it is assumed hugetlb flag must have been cleared when calling folio_put() in update_and_free_hugetlb_folio(). This assumption is broken due to below race: CPU1 CPU2 dissolve_free_huge_page update_and_free_pages_bulk update_and_free_hugetlb_folio hugetlb_vmemmap_restore_folios folio_clear_hugetlb_vmemmap_optimized clear_flag = folio_test_hugetlb_vmemmap_optimized if (clear_flag) <-- False, it's already cleared. __folio_clear_hugetlb(folio) <-- Hugetlb is not cleared. folio_put free_huge_folio <-- free_the_page is expected. list_for_each_entry() __folio_clear_hugetlb <-- Too late. Fix this issue by checking whether folio is hugetlb directly instead of checking clear_flag to close the race window. Link: https://lkml.kernel.org/r/20240419085819.1901645-1-linmiaohe@huawei.com Fixes: 32c877191e02 ("hugetlb: do not clear hugetlb dtor until allocating vmemmap") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-debug_locks_warn_on1-when-dissolve_free_hugetlb_folio +++ a/mm/hugetlb.c @@ -1781,7 +1781,7 @@ static void __update_and_free_hugetlb_fo * If vmemmap pages were allocated above, then we need to clear the * hugetlb destructor under the hugetlb lock. */ - if (clear_dtor) { + if (folio_test_hugetlb(folio)) { spin_lock_irq(&hugetlb_lock); __clear_hugetlb_destructor(h, folio); spin_unlock_irq(&hugetlb_lock); _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are

1 year, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024