- Linux-stable-mirror - lists.linaro.org

[PATCH v2] intel_th: Fix error handling in intel_th_output_open

by Ma Ke

intel_th_output_open() calls bus_find_device_by_devt() which internally increments the device reference count via get_device(), but this reference is not properly released in several error paths. When device driver is unavailable, file operations cannot be obtained, or the driver's open method fails, the function returns without calling put_device(), leading to a permanent device reference count leak. This prevents the device from being properly released and could cause resource exhaustion over time. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 39f4034693b7 ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch to fix uninitialized variable 'err' warnings. --- drivers/hwtracing/intel_th/core.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c index 47d9e6c3bac0..fdb9d022d875 100644 --- a/drivers/hwtracing/intel_th/core.c +++ b/drivers/hwtracing/intel_th/core.c @@ -810,13 +810,17 @@ static int intel_th_output_open(struct inode *inode, struct file *file) int err; dev = bus_find_device_by_devt(&intel_th_bus, inode->i_rdev); - if (!dev || !dev->driver) - return -ENODEV; + if (!dev || !dev->driver) { + err = -ENODEV; + goto out_no_device; + } thdrv = to_intel_th_driver(dev->driver); fops = fops_get(thdrv->fops); - if (!fops) - return -ENODEV; + if (!fops) { + err = -ENODEV; + goto out_put_device; + } replace_fops(file, fops); @@ -824,10 +828,16 @@ static int intel_th_output_open(struct inode *inode, struct file *file) if (file->f_op->open) { err = file->f_op->open(inode, file); - return err; + if (err) + goto out_put_device; } return 0; + +out_put_device: + put_device(dev); +out_no_device: + return err; } static const struct file_operations intel_th_output_fops = { -- 2.17.1

3 weeks, 3 days

1
0
0 0

[PATCH v2 0/2] Enable 1GHz OPP am335x-bonegreen-eco

by Kory Maincent (TI.com)

The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used. Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably. Changes in v2: - Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called. - Add the am335x-bonegreen-eco devicetree change in the same patch series. Signed-off-by: Kory Maincent (TI.com) <kory.maincent(a)bootlin.com> --- Kory Maincent (TI.com) (2): mfd: tps65219: Implement LOCK register handling for TPS65214 ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +- drivers/mfd/tps65219.c | 51 +++++++++++++++++++++- include/linux/mfd/tps65219.h | 2 + 3 files changed, 53 insertions(+), 2 deletions(-) --- base-commit: 1c353dc8d962de652bc7ad2ba2e63f553331391c change-id: 20251106-fix_tps65219-dd62141d22cf Best regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com

3 weeks, 3 days

5
5
0 0

[PATCH v3] PCI: dw-rockchip: Prevent advertising L1 Substates support

by Niklas Cassel

The L1 substates support requires additional steps to work, namely: -Proper handling of the CLKREQ# sideband signal. (It is mostly handled by hardware, but software still needs to set the clkreq fields in the PCIE_CLIENT_POWER_CON register to match the hardware implementation.) -Program the frequency of the aux clock into the DSP_PCIE_PL_AUX_CLK_FREQ_OFF register. (During L1 substates the core_clk is turned off and the aux_clk is used instead.) These steps are currently missing from the driver. For more details, see section '18.6.6.4 L1 Substate' in the RK3658 TRM 1.1 Part 2, or section '11.6.6.4 L1 Substate' in the RK3588 TRM 1.0 Part2. While this has always been a problem when using e.g. CONFIG_PCIEASPM_POWER_SUPERSAVE=y, or when modifying /sys/bus/pci/devices/.../link/l1_2_aspm, the lacking driver support for L1 substates became more apparent after commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms"), which enabled ASPM also for CONFIG_PCIEASPM_DEFAULT=y. When using e.g. an NVMe drive connected to the PCIe controller, the problem will be seen as: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 nvme nvme0: Does your device have a faulty power saving mode enabled? nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug Thus, prevent advertising L1 Substates support until proper driver support is added. Cc: stable(a)vger.kernel.org Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Fixes: f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") Acked-by: Shawn Lin <shawn.lin(a)rock-chips.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- Changes since v2: -Improve commit message (Bjorn) drivers/pci/controller/dwc/pcie-dw-rockchip.c | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index 3e2752c7dd09..84f882abbca5 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -200,6 +200,25 @@ static bool rockchip_pcie_link_up(struct dw_pcie *pci) return FIELD_GET(PCIE_LINKUP_MASK, val) == PCIE_LINKUP; } +/* + * See e.g. section '11.6.6.4 L1 Substate' in the RK3588 TRM V1.0 for the steps + * needed to support L1 substates. Currently, not a single rockchip platform + * performs these steps, so disable L1 substates until there is proper support. + */ +static void rockchip_pcie_disable_l1sub(struct dw_pcie *pci) +{ + u32 cap, l1subcap; + + cap = dw_pcie_find_ext_capability(pci, PCI_EXT_CAP_ID_L1SS); + if (cap) { + l1subcap = dw_pcie_readl_dbi(pci, cap + PCI_L1SS_CAP); + l1subcap &= ~(PCI_L1SS_CAP_L1_PM_SS | PCI_L1SS_CAP_ASPM_L1_1 | + PCI_L1SS_CAP_ASPM_L1_2 | PCI_L1SS_CAP_PCIPM_L1_1 | + PCI_L1SS_CAP_PCIPM_L1_2); + dw_pcie_writel_dbi(pci, cap + PCI_L1SS_CAP, l1subcap); + } +} + static void rockchip_pcie_enable_l0s(struct dw_pcie *pci) { u32 cap, lnkcap; @@ -264,6 +283,7 @@ static int rockchip_pcie_host_init(struct dw_pcie_rp *pp) irq_set_chained_handler_and_data(irq, rockchip_pcie_intx_handler, rockchip); + rockchip_pcie_disable_l1sub(pci); rockchip_pcie_enable_l0s(pci); return 0; @@ -301,6 +321,7 @@ static void rockchip_pcie_ep_init(struct dw_pcie_ep *ep) struct dw_pcie *pci = to_dw_pcie_from_ep(ep); enum pci_barno bar; + rockchip_pcie_disable_l1sub(pci); rockchip_pcie_enable_l0s(pci); rockchip_pcie_ep_hide_broken_ats_cap_rk3588(ep); -- 2.51.0

3 weeks, 3 days

5
17
0 0

[PATCH stable] fbdev: Fix out-of-bounds issue in sys_fillrect()

by Gu Bowen

There was an out-of-bounds issue found by syzkaller test on v6.6. BUG: unable to handle page fault for address: ffffc90000c3f000 PGD 100000067 P4D 100000067 PUD 100c80067 PMD 10ac1c067 PTE 0 Oops: 0002 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 6521 Comm: syz.3.1365 Not tainted 6.6.0+ #82 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:memset64 arch/x86/include/asm/string_64.h:58 [inline] RIP: 0010:memset_l include/linux/string.h:168 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/sysfillrect.c:53 [inline] RIP: 0010:bitfill_aligned+0x144/0x1c0 drivers/video/fbdev/core/sysfillrect.c:25 Code: 23 04 24 48 31 d0 49 89 46 f8 44 89 e0 44 29 f8 29 c3 e8 9f 39 49 fe 89 d8 31 d2 4c 89 f7 41 f7 f4 48 89 c3 48 89 c1 48 89 e8 <f3> 48 ab 31 ff 4c 89 ee e8 df 2f 49 fe 4d 85 ed 0f 84 6b ff ff ff RSP: 0018:ffff888119ce7418 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000180 RCX: 0000000000000180 RDX: 0000000000000000 RSI: ffffc90003873000 RDI: ffffc90000c3f000 RBP: 0000000000000000 R08: 0000000000006000 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000040 R13: 0000000000000000 R14: ffffc90000c3f000 R15: 0000000000000000 FS: 00007f1704b926c0(0000) GS:ffff8881f5980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000c3f000 CR3: 00000001230d0002 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 000000000000e000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> sys_fillrect+0x429/0x830 drivers/video/fbdev/core/sysfillrect.c:281 drm_fbdev_generic_defio_fillrect+0x27/0x140 drivers/gpu/drm/drm_fbdev_generic.c:37 bit_clear+0x183/0x220 drivers/video/fbdev/core/bitblit.c:73 __fbcon_clear+0x5ea/0x670 drivers/video/fbdev/core/fbcon.c:1281 fbcon_scroll+0x41e/0x560 drivers/video/fbdev/core/fbcon.c:1847 con_scroll+0x464/0x6a0 drivers/tty/vt/vt.c:577 lf+0x274/0x2d0 drivers/tty/vt/vt.c:1461 do_con_trol+0x5ea/0x3d80 drivers/tty/vt/vt.c:2149 do_con_write+0x780/0x10c0 drivers/tty/vt/vt.c:2905 con_write+0x28/0xc0 drivers/tty/vt/vt.c:3245 do_output_char+0x5de/0x850 drivers/tty/n_tty.c:433 process_output drivers/tty/n_tty.c:500 [inline] n_tty_write+0x442/0xb00 drivers/tty/n_tty.c:2406 iterate_tty_write+0x2b5/0x630 drivers/tty/tty_io.c:1017 file_tty_write.constprop.0+0x20c/0x3b0 drivers/tty/tty_io.c:1088 call_write_iter include/linux/fs.h:2085 [inline] do_iter_readv_writev+0x210/0x3c0 fs/read_write.c:737 do_iter_write+0x181/0x4e0 fs/read_write.c:862 vfs_writev+0x15b/0x4d0 fs/read_write.c:935 do_writev+0x136/0x370 fs/read_write.c:978 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 When the virtual console is rotated in the backend state, it can lead to inconsistencies between the size of the virtual console's size and its hook functions. In such cases, clearing the screen may result in out-of-bounds issue. Fix it by adding a check in sys_fillrect() and moving set_blitting_type() to the visible area of the VC. CC: stable(a)vger.kernel.org # fbdev had been refactored on 6.15-rc1 Fixes: 68648ed1f58d ("fbdev: add drawing functions for framebuffers in system RAM") Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/video/fbdev/core/fbcon.c | 2 +- drivers/video/fbdev/core/sysfillrect.c | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index b49f15a3442e..a6602f230089 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2702,9 +2702,9 @@ static void fbcon_modechanged(struct fb_info *info) return; p = &fb_display[vc->vc_num]; - set_blitting_type(vc, info); if (con_is_visible(vc)) { + set_blitting_type(vc, info); var_to_display(p, &info->var, info); cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); diff --git a/drivers/video/fbdev/core/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c index bcdcaeae6538..e5c4ee317b0b 100644 --- a/drivers/video/fbdev/core/sysfillrect.c +++ b/drivers/video/fbdev/core/sysfillrect.c @@ -238,6 +238,7 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect) u32 bpp = p->var.bits_per_pixel; unsigned long *dst; int dst_idx, left; + long dst_offset; if (p->state != FBINFO_STATE_RUNNING) return; @@ -277,6 +278,11 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect) } while (height--) { dst += dst_idx >> (ffs(bits) - 1); + dst_offset = (unsigned long)dst - (unsigned long)p->screen_base; + if (dst_offset < 0 || dst_offset >= p->fix.smem_len) { + pr_err("dst offset out of bound: dst_offset(%ld)", dst_offset); + return; + } dst_idx &= (bits - 1); fill_op32(p, dst, dst_idx, pat, width*bpp, bits); dst_idx += p->fix.line_length*8; -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH] net: Fix error handling in netdev_register_kobject

by Ma Ke

After calling device_initialize(), the reference count of the device is set to 1. If device_add() fails or register_queue_kobjects() fails, the function returns without calling put_device() to release the initial reference, causing a memory leak of the device structure. Similarly, in netdev_unregister_kobject(), after calling device_del(), there is no call to put_device() to release the initial reference, leading to a memory leak. Add put_device() in the error paths of netdev_register_kobject() and after device_del() in netdev_unregister_kobject() to properly release the device references. Found by code review. Cc: stable(a)vger.kernel.org Fixes: a1b3f594dc5f ("net: Expose all network devices in a namespaces in sysfs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- net/core/net-sysfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index ca878525ad7c..d3895f26a0c8 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -2327,6 +2327,7 @@ void netdev_unregister_kobject(struct net_device *ndev) pm_runtime_set_memalloc_noio(dev, false); device_del(dev); + put_device(dev); } /* Create sysfs entries for network device. */ @@ -2357,7 +2358,7 @@ int netdev_register_kobject(struct net_device *ndev) error = device_add(dev); if (error) - return error; + goto out_put_device; error = register_queue_kobjects(ndev); if (error) { @@ -2367,6 +2368,10 @@ int netdev_register_kobject(struct net_device *ndev) pm_runtime_set_memalloc_noio(dev, true); + return 0; + +out_put_device: + put_device(dev); return error; } -- 2.17.1

3 weeks, 3 days

4
3
0 0

[PATCH] arm64/pageattr: Propagate return value from __change_memory_common

by Dev Jain

Post a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full"), __change_memory_common has a real chance of failing due to split failure. Before that commit, this line was introduced in c55191e96caa, still having a chance of failing if it needs to allocate pagetable memory in apply_to_page_range, although that has never been observed to be true. In general, we should always propagate the return value to the caller. Cc: stable(a)vger.kernel.org Fixes: c55191e96caa ("arm64: mm: apply r/o permissions of VM areas to its linear alias as well") Signed-off-by: Dev Jain <dev.jain(a)arm.com> --- Based on Linux 6.18-rc4. arch/arm64/mm/pageattr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c index 5135f2d66958..b4ea86cd3a71 100644 --- a/arch/arm64/mm/pageattr.c +++ b/arch/arm64/mm/pageattr.c @@ -148,6 +148,7 @@ static int change_memory_common(unsigned long addr, int numpages, unsigned long size = PAGE_SIZE * numpages; unsigned long end = start + size; struct vm_struct *area; + int ret; int i; if (!PAGE_ALIGNED(addr)) { @@ -185,8 +186,10 @@ static int change_memory_common(unsigned long addr, int numpages, if (rodata_full && (pgprot_val(set_mask) == PTE_RDONLY || pgprot_val(clear_mask) == PTE_RDONLY)) { for (i = 0; i < area->nr_pages; i++) { - __change_memory_common((u64)page_address(area->pages[i]), + ret = __change_memory_common((u64)page_address(area->pages[i]), PAGE_SIZE, set_mask, clear_mask); + if (ret) + return ret; } } -- 2.30.2

3 weeks, 3 days

5
21
0 0

[PATCH v2 01/17] drm/xe/svm: Fix a debug printout

by Thomas Hellström

Avoid spamming the log with drm_info(). Use drm_dbg() instead. Fixes: cc795e041034 ("drm/xe/svm: Make xe_svm_range_needs_migrate_to_vram() public") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.17+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c index 55c5a0eb82e1..894e8f092e3f 100644 --- a/drivers/gpu/drm/xe/xe_svm.c +++ b/drivers/gpu/drm/xe/xe_svm.c @@ -941,7 +941,7 @@ bool xe_svm_range_needs_migrate_to_vram(struct xe_svm_range *range, struct xe_vm xe_assert(vm->xe, IS_DGFX(vm->xe)); if (xe_svm_range_in_vram(range)) { - drm_info(&vm->xe->drm, "Range is already in VRAM\n"); + drm_dbg(&vm->xe->drm, "Range is already in VRAM\n"); return false; } -- 2.51.1

3 weeks, 3 days

2
1
0 0

[PATCH stable] notifiers: Add oops check in blocking_notifier_call_chain()

by Yi Yang

In hrtimer_interrupt(), interrupts are disabled when acquiring a spinlock, which subsequently triggers an oops. During the oops call chain, blocking_notifier_call_chain() invokes _cond_resched, ultimately leading to a hard lockup. Call Stack: hrtimer_interrupt//raw_spin_lock_irqsave __hrtimer_run_queues page_fault do_page_fault bad_area_nosemaphore no_context oops_end bust_spinlocks unblank_screen do_unblank_screen fbcon_blank fb_notifier_call_chain blocking_notifier_call_chain down_read _cond_resched If the system is in an oops state, use down_read_trylock instead of a blocking lock acquisition. If the trylock fails, skip executing the notifier callbacks to avoid potential deadlocks or unsafe operations during the oops handling process. Cc: stable(a)vger.kernel.org # 6.6 Fixes: fe9d4f576324 ("Add kernel/notifier.c") Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- kernel/notifier.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/kernel/notifier.c b/kernel/notifier.c index b3ce28f39eb6..ebff2315fac2 100644 --- a/kernel/notifier.c +++ b/kernel/notifier.c @@ -384,9 +384,18 @@ int blocking_notifier_call_chain(struct blocking_notifier_head *nh, * is, we re-check the list after having taken the lock anyway: */ if (rcu_access_pointer(nh->head)) { - down_read(&nh->rwsem); - ret = notifier_call_chain(&nh->head, val, v, -1, NULL); - up_read(&nh->rwsem); + if (!oops_in_progress) { + down_read(&nh->rwsem); + ret = notifier_call_chain(&nh->head, val, v, -1, NULL); + up_read(&nh->rwsem); + } else { + if (down_read_trylock(&nh->rwsem)) { + ret = notifier_call_chain(&nh->head, val, v, -1, NULL); + up_read(&nh->rwsem); + } else { + ret = NOTIFY_BAD; + } + } } return ret; } -- 2.25.1

3 weeks, 3 days

3
3
0 0

[PATCH net 0/6] selftests: mptcp: join: fix some flaky tests

by Matthieu Baerts (NGI0)

When looking at the recent CI results on NIPA and MPTCP CIs, a few MPTCP Join tests are marked as unstable. Here are some fixes for that. - Patch 1: a small fix for mptcp_connect.sh, printing a note as initially intended. For >=v5.13. - Patch 2: avoid unexpected reset when closing subflows. For >= 5.13. - Patches 3-4: longer transfer when not waiting for the end. For >=5.18. - Patch 5: read all received data when expecting a reset. For >= v6.1. - Patch 6: a fix to properly kill background tasks. For >= v6.5. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (6): selftests: mptcp: connect: fix fallback note due to OoO selftests: mptcp: join: rm: set backup flag selftests: mptcp: join: endpoints: longer transfer selftests: mptcp: join: userspace: longer transfer selftests: mptcp: connect: trunc: read all recv data selftests: mptcp: join: properly kill background tasks tools/testing/selftests/net/mptcp/mptcp_connect.c | 18 +++-- tools/testing/selftests/net/mptcp/mptcp_connect.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 90 +++++++++++----------- tools/testing/selftests/net/mptcp/mptcp_lib.sh | 21 +++++ 4 files changed, 80 insertions(+), 51 deletions(-) --- base-commit: 96a9178a29a6b84bb632ebeb4e84cf61191c73d5 change-id: 20251108-net-mptcp-sft-join-unstable-5a28cdb6ea54 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

3 weeks, 4 days

3
8
0 0

FAILED: patch "[PATCH] rust: kbuild: treat `build_error` and `rustdoc` as kernel" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 16c43a56b79e2c3220b043236369a129d508c65a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110816-catalog-residency-716f@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 16c43a56b79e2c3220b043236369a129d508c65a Mon Sep 17 00:00:00 2001 From: Miguel Ojeda <ojeda(a)kernel.org> Date: Sun, 2 Nov 2025 22:28:52 +0100 Subject: [PATCH] rust: kbuild: treat `build_error` and `rustdoc` as kernel objects Even if normally `build_error` isn't a kernel object, it should still be treated as such so that we pass the same flags. Similarly, `rustdoc` targets are never kernel objects, but we need to treat them as such. Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc` will complain about missing sanitizer flags since `-Zsanitizer` is a target modifier too [1]: error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error` --> rust/build_error.rs:3:1 | 3 | //! Build-time error. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error Thus explicitly mark them as kernel objects. Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138736 [1] Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Tested-by: Justin M. Forbes <jforbes(a)fedoraproject.org> Link: https://patch.msgid.link/20251102212853.1505384-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> diff --git a/rust/Makefile b/rust/Makefile index 23c7ae905bd2..a9fb9354b659 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -127,9 +127,14 @@ rustdoc-core: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs rustdoc-core: $(RUST_LIB_SRC)/core/src/lib.rs rustdoc-clean FORCE +$(call if_changed,rustdoc) +# Even if `rustdoc` targets are not kernel objects, they should still be +# treated as such so that we pass the same flags. Otherwise, for instance, +# `rustdoc` will complain about missing sanitizer flags causing an ABI mismatch. +rustdoc-compiler_builtins: private is-kernel-object := y rustdoc-compiler_builtins: $(src)/compiler_builtins.rs rustdoc-core FORCE +$(call if_changed,rustdoc) +rustdoc-ffi: private is-kernel-object := y rustdoc-ffi: $(src)/ffi.rs rustdoc-core FORCE +$(call if_changed,rustdoc) @@ -147,6 +152,7 @@ rustdoc-pin_init: $(src)/pin-init/src/lib.rs rustdoc-pin_init_internal \ rustdoc-macros FORCE +$(call if_changed,rustdoc) +rustdoc-kernel: private is-kernel-object := y rustdoc-kernel: private rustc_target_flags = --extern ffi --extern pin_init \ --extern build_error --extern macros \ --extern bindings --extern uapi @@ -522,6 +528,10 @@ $(obj)/pin_init.o: $(src)/pin-init/src/lib.rs $(obj)/compiler_builtins.o \ $(obj)/$(libpin_init_internal_name) $(obj)/$(libmacros_name) FORCE +$(call if_changed_rule,rustc_library) +# Even if normally `build_error` is not a kernel object, it should still be +# treated as such so that we pass the same flags. Otherwise, for instance, +# `rustc` will complain about missing sanitizer flags causing an ABI mismatch. +$(obj)/build_error.o: private is-kernel-object := y $(obj)/build_error.o: private skip_gendwarfksyms = 1 $(obj)/build_error.o: $(src)/build_error.rs $(obj)/compiler_builtins.o FORCE +$(call if_changed_rule,rustc_library)

3 weeks, 4 days

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror