Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

266 participants
124087 discussions

[PATCH] gpio: rockchip: mark the GPIO controller as sleeping

by Bartosz Golaszewski

The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This can cause the following lockdep splat with shared GPIOs enabled on boards which have multiple devices using the same GPIO: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 12, name: kworker/u16:0 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 6 locks held by kworker/u16:0/12: #0: ffff0001f0018d48 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_one_work+0x18c/0x604 #1: ffff8000842dbdf0 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1b4/0x604 #2: ffff0001f18498f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x38/0x1b0 #3: ffff0001f75f1e90 (&gdev->srcu){.+.?}-{0:0}, at: gpiod_direction_output_raw_commit+0x0/0x360 #4: ffff0001f46e3db8 (&shared_desc->spinlock){....}-{3:3}, at: gpio_shared_proxy_direction_output+0xd0/0x144 [gpio_shared_proxy] #5: ffff0001f180ee90 (&gdev->srcu){.+.?}-{0:0}, at: gpiod_direction_output_raw_commit+0x0/0x360 irq event stamp: 81450 hardirqs last enabled at (81449): [<ffff8000813acba4>] _raw_spin_unlock_irqrestore+0x74/0x78 hardirqs last disabled at (81450): [<ffff8000813abfb8>] _raw_spin_lock_irqsave+0x84/0x88 softirqs last enabled at (79616): [<ffff8000811455fc>] __alloc_skb+0x17c/0x1e8 softirqs last disabled at (79614): [<ffff8000811455fc>] __alloc_skb+0x17c/0x1e8 CPU: 2 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.0-rc4-next-20260105+ #11975 PREEMPT Hardware name: Hardkernel ODROID-M1 (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x24 __might_resched+0x144/0x248 __might_sleep+0x48/0x98 __mutex_lock+0x5c/0x894 mutex_lock_nested+0x24/0x30 pinctrl_get_device_gpio_range+0x44/0x128 pinctrl_gpio_direction+0x3c/0xe0 pinctrl_gpio_direction_output+0x14/0x20 rockchip_gpio_direction_output+0xb8/0x19c gpiochip_direction_output+0x38/0x94 gpiod_direction_output_raw_commit+0x1d8/0x360 gpiod_direction_output_nonotify+0x7c/0x230 gpiod_direction_output+0x34/0xf8 gpio_shared_proxy_direction_output+0xec/0x144 [gpio_shared_proxy] gpiochip_direction_output+0x38/0x94 gpiod_direction_output_raw_commit+0x1d8/0x360 gpiod_direction_output_nonotify+0x7c/0x230 gpiod_configure_flags+0xbc/0x480 gpiod_find_and_request+0x1a0/0x574 gpiod_get_index+0x58/0x84 devm_gpiod_get_index+0x20/0xb4 devm_gpiod_get_optional+0x18/0x30 rockchip_pcie_probe+0x98/0x380 platform_probe+0x5c/0xac really_probe+0xbc/0x298 Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Cc: stable(a)vger.kernel.org Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Closes: https://lore.kernel.org/all/d035fc29-3b03-4cd6-b8ec-001f93540bc6@samsung.co… Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)oss.qualcomm.com> --- drivers/gpio/gpio-rockchip.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c index 47174eb3ba76..bae2061f15fc 100644 --- a/drivers/gpio/gpio-rockchip.c +++ b/drivers/gpio/gpio-rockchip.c @@ -593,6 +593,7 @@ static int rockchip_gpiolib_register(struct rockchip_pin_bank *bank) gc->ngpio = bank->nr_pins; gc->label = bank->name; gc->parent = bank->dev; + gc->can_sleep = true; ret = gpiochip_add_data(gc, bank); if (ret) { -- 2.47.3

1 day, 21 hours

[PATCH] bus: fsl-mc: fix use-after-free in driver_override_show()

by Gui-Dong Han

The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation. Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- I verified this with a stress test that continuously writes/reads the attribute. It triggered KASAN and leaked bytes like a0 f4 81 9f a3 ff ff (likely kernel pointers). Since driver_override is world-readable (0644), this allows unprivileged users to leak kernel pointers and bypass KASLR. Similar races were fixed in other buses (e.g., commits 9561475db680 and 91d44c1afc61). Currently, 9 of 11 buses handle this correctly; this patch fixes one of the remaining two. --- drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 25845c04e562..a97baf2cbcdd 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -202,8 +202,12 @@ static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr, char *buf) { struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); + ssize_t len; - return sysfs_emit(buf, "%s\n", mc_dev->driver_override); + device_lock(dev); + len = sysfs_emit(buf, "%s\n", mc_dev->driver_override); + device_unlock(dev); + return len; } static DEVICE_ATTR_RW(driver_override); -- 2.43.0

1 day, 22 hours

[PATCH v2 2/2] platform/x86: ISST: Store and restore all domains data

by Srinivas Pandruvada

The suspend/resume callbacks currently only store and restore the configuration for power domain 0. However, other power domains may also have modified configurations that need to be preserved across suspend/ resume cycles. Extend the store/restore functionality to handle all power domains. Fixes: 91576acab020 ("platform/x86: ISST: Add suspend/resume callbacks") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> CC: stable(a)vger.kernel.org --- v2: - Remove new line in tpmi_sst_dev_suspend() after cp_base assignment .../intel/speed_select_if/isst_tpmi_core.c | 54 +++++++++++-------- 1 file changed, 33 insertions(+), 21 deletions(-) diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c index f587709ddd47..13b11c3a2ec4 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c @@ -1723,55 +1723,67 @@ EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_remove, "INTEL_TPMI_SST"); void tpmi_sst_dev_suspend(struct auxiliary_device *auxdev) { struct tpmi_sst_struct *tpmi_sst = auxiliary_get_drvdata(auxdev); - struct tpmi_per_power_domain_info *power_domain_info; + struct tpmi_per_power_domain_info *power_domain_info, *pd_info; struct oobmsm_plat_info *plat_info; void __iomem *cp_base; + int num_resources, i; plat_info = tpmi_get_platform_data(auxdev); if (!plat_info) return; power_domain_info = tpmi_sst->power_domain_info[plat_info->partition]; + num_resources = tpmi_sst->number_of_power_domains[plat_info->partition]; - cp_base = power_domain_info->sst_base + power_domain_info->sst_header.cp_offset; - power_domain_info->saved_sst_cp_control = readq(cp_base + SST_CP_CONTROL_OFFSET); - - memcpy_fromio(power_domain_info->saved_clos_configs, cp_base + SST_CLOS_CONFIG_0_OFFSET, - sizeof(power_domain_info->saved_clos_configs)); + for (i = 0; i < num_resources; i++) { + pd_info = &power_domain_info[i]; + if (!pd_info || !pd_info->sst_base) + continue; - memcpy_fromio(power_domain_info->saved_clos_assocs, cp_base + SST_CLOS_ASSOC_0_OFFSET, - sizeof(power_domain_info->saved_clos_assocs)); + cp_base = pd_info->sst_base + pd_info->sst_header.cp_offset; + pd_info->saved_sst_cp_control = readq(cp_base + SST_CP_CONTROL_OFFSET); + memcpy_fromio(pd_info->saved_clos_configs, cp_base + SST_CLOS_CONFIG_0_OFFSET, + sizeof(pd_info->saved_clos_configs)); + memcpy_fromio(pd_info->saved_clos_assocs, cp_base + SST_CLOS_ASSOC_0_OFFSET, + sizeof(pd_info->saved_clos_assocs)); - power_domain_info->saved_pp_control = readq(power_domain_info->sst_base + - power_domain_info->sst_header.pp_offset + - SST_PP_CONTROL_OFFSET); + pd_info->saved_pp_control = readq(pd_info->sst_base + + pd_info->sst_header.pp_offset + + SST_PP_CONTROL_OFFSET); + } } EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_suspend, "INTEL_TPMI_SST"); void tpmi_sst_dev_resume(struct auxiliary_device *auxdev) { struct tpmi_sst_struct *tpmi_sst = auxiliary_get_drvdata(auxdev); - struct tpmi_per_power_domain_info *power_domain_info; + struct tpmi_per_power_domain_info *power_domain_info, *pd_info; struct oobmsm_plat_info *plat_info; void __iomem *cp_base; + int num_resources, i; plat_info = tpmi_get_platform_data(auxdev); if (!plat_info) return; power_domain_info = tpmi_sst->power_domain_info[plat_info->partition]; + num_resources = tpmi_sst->number_of_power_domains[plat_info->partition]; - cp_base = power_domain_info->sst_base + power_domain_info->sst_header.cp_offset; - writeq(power_domain_info->saved_sst_cp_control, cp_base + SST_CP_CONTROL_OFFSET); - - memcpy_toio(cp_base + SST_CLOS_CONFIG_0_OFFSET, power_domain_info->saved_clos_configs, - sizeof(power_domain_info->saved_clos_configs)); + for (i = 0; i < num_resources; i++) { + pd_info = &power_domain_info[i]; + if (!pd_info || !pd_info->sst_base) + continue; - memcpy_toio(cp_base + SST_CLOS_ASSOC_0_OFFSET, power_domain_info->saved_clos_assocs, - sizeof(power_domain_info->saved_clos_assocs)); + cp_base = pd_info->sst_base + pd_info->sst_header.cp_offset; + writeq(pd_info->saved_sst_cp_control, cp_base + SST_CP_CONTROL_OFFSET); + memcpy_toio(cp_base + SST_CLOS_CONFIG_0_OFFSET, pd_info->saved_clos_configs, + sizeof(pd_info->saved_clos_configs)); + memcpy_toio(cp_base + SST_CLOS_ASSOC_0_OFFSET, pd_info->saved_clos_assocs, + sizeof(pd_info->saved_clos_assocs)); - writeq(power_domain_info->saved_pp_control, power_domain_info->sst_base + - power_domain_info->sst_header.pp_offset + SST_PP_CONTROL_OFFSET); + writeq(pd_info->saved_pp_control, power_domain_info->sst_base + + pd_info->sst_header.pp_offset + SST_PP_CONTROL_OFFSET); + } } EXPORT_SYMBOL_NS_GPL(tpmi_sst_dev_resume, "INTEL_TPMI_SST"); -- 2.52.0

2 days

[PATCH v2 1/2] platform/x86: ISST: Add missing write block check

by Srinivas Pandruvada

If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked feature status") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> --- v2: - No change drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c index 34bff2f65a83..f587709ddd47 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c @@ -612,6 +612,9 @@ static long isst_if_core_power_state(void __user *argp) return -EINVAL; if (core_power.get_set) { + if (power_domain_info->write_blocked) + return -EPERM; + _write_cp_info("cp_enable", core_power.enable, SST_CP_CONTROL_OFFSET, SST_CP_ENABLE_START, SST_CP_ENABLE_WIDTH, SST_MUL_FACTOR_NONE) _write_cp_info("cp_prio_type", core_power.priority_type, SST_CP_CONTROL_OFFSET, -- 2.52.0

2 days

[PATCH] xfs: fix NULL ptr in xfs_attr_leaf_get

by Mark Tinguely

The error path of xfs_attr_leaf_hasname() can leave a NULL xfs_buf pointer. xfs_has_attr() checks for the NULL pointer but the other callers do not. We tripped over the NULL pointer in xfs_attr_leaf_get() but fix the other callers too. Fixes v5.8-rc4-95-g07120f1abdff ("xfs: Add xfs_has_attr and subroutines") No reproducer. Cc: stable(a)vger.kernel.org # v5.19+ with another port for v5.9 - v5.18 Signed-off-by: Mark Tinguely <mark.tinguely(a)oracle.com> --- fs/xfs/libxfs/xfs_attr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index 8c04acd30d48..25e2ecf20d14 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -1266,7 +1266,8 @@ xfs_attr_leaf_removename( error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { - xfs_trans_brelse(args->trans, bp); + if (bp) + xfs_trans_brelse(args->trans, bp); if (args->op_flags & XFS_DA_OP_RECOVERY) return 0; return error; @@ -1305,7 +1306,8 @@ xfs_attr_leaf_get(xfs_da_args_t *args) error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { - xfs_trans_brelse(args->trans, bp); + if (bp) + xfs_trans_brelse(args->trans, bp); return error; } else if (error != -EEXIST) return error; -- 2.50.1 (Apple Git-155)

2 days

[PATCH v2] rust: bitops: fix missing _find_* functions on 32-bit ARM

by Alice Ryhl

On 32-bit ARM, you may encounter linker errors such as this one: ld.lld: error: undefined symbol: _find_next_zero_bit >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a This error occurs because even though the functions are declared by include/linux/find.h, the definition is #ifdef'd out on 32-bit ARM. This is because arch/arm/include/asm/bitops.h contains: #define find_first_zero_bit(p,sz) _find_first_zero_bit_le(p,sz) #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off) #define find_first_bit(p,sz) _find_first_bit_le(p,sz) #define find_next_bit(p,sz,off) _find_next_bit_le(p,sz,off) And the underscore-prefixed function is conditional on #ifndef of the non-underscore-prefixed name, but the declaration in find.h is *not* conditional on that #ifndef. To fix the linker error, we ensure that the symbols in question exist when compiling Rust code. We do this by definining them in rust/helpers/ whenever the normal definition is #ifndef'd out. Note that these helpers are somewhat unusual in that they do not have the rust_helper_ prefix that most helpers have. Adding the rust_helper_ prefix does not compile, as 'bindings::_find_next_zero_bit()' will result in a call to a symbol called _find_next_zero_bit as defined by include/linux/find.h rather than a symbol with the rust_helper_ prefix. This is because when a symbol is present in both include/ and rust/helpers/, the one from include/ wins under the assumption that the current configuration is one where that helper is unnecessary. This heuristic fails for _find_next_zero_bit() because the header file always declares it even if the symbol does not exist. The functions still use the __rust_helper annotation. This lets the wrapper function be inlined into Rust code even if full kernel LTO is not used once the patch series for that feature lands. Cc: stable(a)vger.kernel.org Fixes: 6cf93a9ed39e ("rust: add bindings for bitops.h") Reported-by: Andreas Hindborg <a.hindborg(a)kernel.org> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/5616773… Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- Changes in v2: - Remove rust_helper_ prefix from helpers. - Improve commit message. - The set of functions for which a helper is added is changed so that it matches arch/arm/include/asm/bitops.h - Link to v1: https://lore.kernel.org/r/20251203-bitops-find-helper-v1-1-5193deb57766@goo… --- rust/helpers/bitops.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/rust/helpers/bitops.c b/rust/helpers/bitops.c index 5d0861d29d3f0d705a014ae4601685828405f33b..e79ef9e6d98f969e2a0a2a6f62d9fcec3ef0fd72 100644 --- a/rust/helpers/bitops.c +++ b/rust/helpers/bitops.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include <linux/bitops.h> +#include <linux/find.h> void rust_helper___set_bit(unsigned long nr, unsigned long *addr) { @@ -21,3 +22,44 @@ void rust_helper_clear_bit(unsigned long nr, volatile unsigned long *addr) { clear_bit(nr, addr); } + +/* + * The rust_helper_ prefix is intentionally omitted below so that the + * declarations in include/linux/find.h are compatible with these helpers. + * + * Note that the below #ifdefs mean that the helper is only created if C does + * not provide a definition. + */ +#ifdef find_first_zero_bit +__rust_helper +unsigned long _find_first_zero_bit(const unsigned long *p, unsigned long size) +{ + return find_first_zero_bit(p, size); +} +#endif /* find_first_zero_bit */ + +#ifdef find_next_zero_bit +__rust_helper +unsigned long _find_next_zero_bit(const unsigned long *addr, + unsigned long size, unsigned long offset) +{ + return find_next_zero_bit(addr, size, offset); +} +#endif /* find_next_zero_bit */ + +#ifdef find_first_bit +__rust_helper +unsigned long _find_first_bit(const unsigned long *addr, unsigned long size) +{ + return find_first_bit(addr, size); +} +#endif /* find_first_bit */ + +#ifdef find_next_bit +__rust_helper +unsigned long _find_next_bit(const unsigned long *addr, unsigned long size, + unsigned long offset) +{ + return find_next_bit(addr, size, offset); +} +#endif /* find_next_bit */ --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251203-bitops-find-helper-25ed1bbae700 Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

2 days

[PATCH v2 1/2] NTB: ntb_transport: Fix too small buffer for debugfs_name

by Koichiro Den

The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: <stable(a)vger.kernel.org> # v3.9+ Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/ntb/ntb_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c index eb875e3db2e3..857c845bfbe8 100644 --- a/drivers/ntb/ntb_transport.c +++ b/drivers/ntb/ntb_transport.c @@ -1236,9 +1236,9 @@ static int ntb_transport_init_queue(struct ntb_transport_ctx *nt, qp->tx_max_entry = tx_size / qp->tx_max_frame; if (nt->debugfs_node_dir) { - char debugfs_name[4]; + char debugfs_name[8]; - snprintf(debugfs_name, 4, "qp%d", qp_num); + snprintf(debugfs_name, sizeof(debugfs_name), "qp%d", qp_num); qp->debugfs_dir = debugfs_create_dir(debugfs_name, nt->debugfs_node_dir); -- 2.51.0

2 days, 1 hour

[PATCH V2 5.15.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

V1 -> V2: - Because `pmd_val` variable broke ppc builds due to its name, renamed it to `_pmd`. see [1]. [1] https://lore.kernel.org/stable/aS7lPZPYuChOTdXU@hyeyoo - Added David Hildenbrand's Acked-by [2], thanks a lot! [2] https://lore.kernel.org/linux-mm/ac8d7137-3819-4a75-9dd3-fb3d2259ebe4@kerne… # TL;DR previous discussion: https://lore.kernel.org/linux-mm/20250921232709.1608699-1-harry.yoo@oracle.… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. Since the code looks bit different due to different semantics of pte_map_offset_lock(), it'd be best to get this reviewed by MM folks. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 121 ++++++++++++++++++---------------------- 5 files changed, 59 insertions(+), 74 deletions(-) -- 2.43.0

2 days, 2 hours

[PATCH V2 5.10.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

V1 -> V2: - Because `pmd_val` variable broke ppc builds due to its name, renamed it to `_pmd`. see [1]. [1] https://lore.kernel.org/stable/aS7lPZPYuChOTdXU@hyeyoo - Added David Hildenbrand's Acked-by [2], thanks a lot! [2] https://lore.kernel.org/linux-mm/ac8d7137-3819-4a75-9dd3-fb3d2259ebe4@kerne… # TL;DR previous discussion: https://lore.kernel.org/linux-mm/20250921232709.1608699-1-harry.yoo@oracle.… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. Since the code looks bit different due to different semantics of pte_map_offset_lock(), it'd be best to get this reviewed by MM folks. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 107 ++++++++++++++++++++++------------------ 5 files changed, 64 insertions(+), 55 deletions(-) -- 2.43.0

2 days, 2 hours

[PATCH v8 2/2] PCI: dwc: Don't return error when wait for link up in dw_pcie_resume_noirq()

by Richard Zhu

When waiting for the PCIe link to come up, both link up and link down are valid results depending on the device state. Since the link may come up later and to get rid of the following mis-reported PM errors. Do not return an -ETIMEDOUT error, as the outcome has already been reported in dw_pcie_wait_for_link(). PM error logs introduced by the -ETIMEDOUT error return. imx6q-pcie 33800000.pcie: Phy link never came up imx6q-pcie 33800000.pcie: PM: dpm_run_callback(): genpd_resume_noirq returns -110 imx6q-pcie 33800000.pcie: PM: failed to resume noirq: error -110 Cc: stable(a)vger.kernel.org Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume functionality") Signed-off-by: Richard Zhu <hongxing.zhu(a)nxp.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> --- drivers/pci/controller/dwc/pcie-designware-host.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c index 06cbfd9e1f1e..025e11ebd571 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -1245,10 +1245,9 @@ int dw_pcie_resume_noirq(struct dw_pcie *pci) if (ret) return ret; - ret = dw_pcie_wait_for_link(pci); - if (ret) - return ret; + /* Ignore errors, the link may come up later */ + dw_pcie_wait_for_link(pci); - return ret; + return 0; } EXPORT_SYMBOL_GPL(dw_pcie_resume_noirq); -- 2.37.1

2 days, 3 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror