March 2025 - Linux-stable-mirror

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

by Takashi Iwai

[ resent due to a wrong address for regression reporting, sorry! ] Hi, we received a bug report showing the regression on 6.13.1 kernel against 6.13.0. The symptom is that Chrome and VSCode stopped working with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker https://bugzilla.suse.com/show_bug.cgi?id=1236943 Quoting from there: """ I use the latest TW on Gnome with a 4K display and 150% scaling. Everything has been working fine, but recently both Chrome and VSCode (installed from official non-openSUSE channels) stopped working with Scaling. .... I am using VSCode with: `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. """ Surprisingly, the bisection pointed to the backport of the commit b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list to iterate simple_offset directories"). Indeed, the revert of this patch on the latest 6.13.4 was confirmed to fix the issue. Also, the reporter verified that the latest 6.14-rc release is still affected, too. For now I have no concrete idea how the patch could break the behavior of a graphical application like the above. Let us know if you need something for debugging. (Or at easiest, join to the bugzilla entry and ask there; or open another bug report at whatever you like.) BTW, I'll be traveling tomorrow, so my reply will be delayed. thanks, Takashi #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943

5 months, 1 week

6
29
0 0

[PATCH 1/2] drm/i915: Schedule the HPD poll init work on an unbound workqueue

by Imre Deak

Disabling HPD polling from i915_hpd_poll_init_work() involves probing all display connectors explicitly to account for lost hotplug interrupts. On some platforms (mostly pre-ICL) with HDMI connectors the I2C EDID bit-banging using udelay() triggers in turn the workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND warning. Fix the above by scheduling i915_hpd_poll_init_work() on a WQ_UNBOUND workqueue. It's ok to use a system WQ, since i915_hpd_poll_init_work() is properly flushed in intel_hpd_cancel_work(). The connector probing from drm_mode_config::output_poll_work resulting in the same warning is fixed by the next patch. Cc: Tejun Heo <tj(a)kernel.org> Cc: Heiner Kallweit <hkallweit1(a)gmail.com> CC: stable(a)vger.kernel.org # 6.5 Suggested-by: Tejun Heo <tj(a)kernel.org> Suggested-by: Heiner Kallweit <hkallweit1(a)gmail.com> Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245 Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c index e8562f6f8bb44..accc2fec562a0 100644 --- a/drivers/gpu/drm/i915/display/intel_hotplug.c +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -774,7 +774,7 @@ void intel_hpd_poll_enable(struct drm_i915_private *dev_priv) * As well, there's no issue if we race here since we always reschedule * this worker anyway */ - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } @@ -803,7 +803,7 @@ void intel_hpd_poll_disable(struct drm_i915_private *dev_priv) return; WRITE_ONCE(dev_priv->display.hotplug.poll_enabled, false); - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } -- 2.37.2

5 months, 1 week

4
5
0 0

[PATCH v2] arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi

by Dragan Simic

The differences in the vendor-approved CPU and GPU OPPs for the standard Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2] come from the latter, presumably, supporting an extended temperature range that's usually associated with industrial applications, despite the two SoC variant datasheets specifying the same upper limit for the allowed ambient temperature for both variants. However, the lower temperature limit is specified much lower for the RK3588J variant. [1][2] To be on the safe side and to ensure maximum longevity of the RK3588J SoCs, only the CPU and GPU OPPs that are declared by the vendor to be always safe for this SoC variant may be provided. As explained by the vendor [3] and according to the RK3588J datasheet, [2] higher-frequency/higher-voltage CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC lifetime expectancy. Presumably, using the higher OPPs may be safe only when not enjoying the assumed extended temperature range that the RK3588J, as an SoC variant targeted specifically at higher-temperature, industrial applications, is made (or binned) for. Anyone able to keep their RK3588J-based board outside the above-presumed extended temperature range at all times, and willing to take the associated risk of possibly reducing the SoC lifetime expectancy, is free to apply a DT overlay that adds the higher CPU and GPU OPPs. With all this and the downstream RK3588(J) DT definitions [4][5] in mind, let's delete the RK3588J CPU and GPU OPPs that are not considered belonging to the normal operation mode for this SoC variant. To quote the RK3588J datasheet [2], "normal mode means the chipset works under safety voltage and frequency; for the industrial environment, highly recommend to keep in normal mode, the lifetime is reasonably guaranteed", while "overdrive mode brings higher frequency, and the voltage will increase accordingly; under the overdrive mode for a long time, the chipset may shorten the lifetime, especially in high-temperature condition". To sum the RK3588J datasheet [2] and the vendor-provided DTs up, [4][5] the maximum allowed CPU core, GPU and NPU frequencies are as follows: IP core | Normal mode | Overdrive mode ------------+-------------+---------------- Cortex-A55 | 1,296 MHz | 1,704 MHz Cortex-A76 | 1,608 MHz | 2,016 MHz GPU | 700 MHz | 850 MHz NPU | 800 MHz | 950 MHz Unfortunately, when it comes to the actual voltages for the RK3588J CPU and GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the downstream kernel code. [4][5] The RK3588J datasheet states that "the max. working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the downstream kernel code actually allows voltage ranges that go up to 0.95 V, which is still within the voltage range allowed by the datasheet. However, the RK3588J datasheet also tells us to "strictly refer to the software configuration of SDK and the hardware reference design", so let's embrace the voltage ranges provided by the downstream kernel code, which also prevents the undesirable theoretical outcome of ending up with no usable OPPs on a particular board, as a result of the board's voltage regulator(s) being unable to deliver the exact voltages, for whatever reason. The above-described voltage ranges for the RK3588J CPU OPPs remain taken from the downstream kernel code [4][5] by picking the highest, worst-bin values, which ensure that all RK3588J bins will work reliably. Yes, with some power inevitably wasted as unnecessarily generated heat, but the reliability is paramount, together with the longevity. This deficiency may be revisited separately at some point in the future. The provided RK3588J CPU OPPs follow the slightly debatable "provide only the highest-frequency OPP from the same-voltage group" approach that's been established earlier, [6] as a result of the "same-voltage, lower-frequency" OPPs being considered inefficient from the IPA governor's standpoint, which may also be revisited separately at some point in the future. [1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1… [2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK35… [3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4… [4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c7… [5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c7… [6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gma… Fixes: 667885a68658 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j") Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j") Cc: stable(a)vger.kernel.org Cc: Heiko Stuebner <heiko(a)sntech.de> Cc: Alexey Charkov <alchark(a)gmail.com> Helped-by: Quentin Schulz <quentin.schulz(a)cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz(a)cherry.de> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- Notes: Changes in v2: - Reworded and expanded the patch description a bit, to include some more information and to make it more clear what are the implied speculations and assumptions, and what are the available official statements from Rockchip, as suggested by Quentin [7] - Collected Reviewed-by tag from Quentin [7] Link to v1: https://lore.kernel.org/linux-rockchip/f929da061de35925ea591c969f985430e23c… [7] https://lore.kernel.org/linux-rockchip/71b7c81b-6a4e-442b-a661-04d63639962a… arch/arm64/boot/dts/rockchip/rk3588j.dtsi | 53 ++++++++--------------- 1 file changed, 17 insertions(+), 36 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi index bce72bac4503..3045cb3bd68c 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi @@ -11,74 +11,59 @@ cluster0_opp_table: opp-table-cluster0 { compatible = "operating-points-v2"; opp-shared; - opp-1416000000 { - opp-hz = /bits/ 64 <1416000000>; + opp-1200000000 { + opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <750000 750000 950000>; clock-latency-ns = <40000>; opp-suspend; }; - opp-1608000000 { - opp-hz = /bits/ 64 <1608000000>; - opp-microvolt = <887500 887500 950000>; - clock-latency-ns = <40000>; - }; - opp-1704000000 { - opp-hz = /bits/ 64 <1704000000>; - opp-microvolt = <937500 937500 950000>; + opp-1296000000 { + opp-hz = /bits/ 64 <1296000000>; + opp-microvolt = <775000 775000 950000>; clock-latency-ns = <40000>; }; }; cluster1_opp_table: opp-table-cluster1 { compatible = "operating-points-v2"; opp-shared; + opp-1200000000{ + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <750000 750000 950000>; + clock-latency-ns = <40000>; + }; opp-1416000000 { opp-hz = /bits/ 64 <1416000000>; - opp-microvolt = <750000 750000 950000>; + opp-microvolt = <762500 762500 950000>; clock-latency-ns = <40000>; }; opp-1608000000 { opp-hz = /bits/ 64 <1608000000>; opp-microvolt = <787500 787500 950000>; clock-latency-ns = <40000>; }; - opp-1800000000 { - opp-hz = /bits/ 64 <1800000000>; - opp-microvolt = <875000 875000 950000>; - clock-latency-ns = <40000>; - }; - opp-2016000000 { - opp-hz = /bits/ 64 <2016000000>; - opp-microvolt = <950000 950000 950000>; - clock-latency-ns = <40000>; - }; }; cluster2_opp_table: opp-table-cluster2 { compatible = "operating-points-v2"; opp-shared; + opp-1200000000{ + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <750000 750000 950000>; + clock-latency-ns = <40000>; + }; opp-1416000000 { opp-hz = /bits/ 64 <1416000000>; - opp-microvolt = <750000 750000 950000>; + opp-microvolt = <762500 762500 950000>; clock-latency-ns = <40000>; }; opp-1608000000 { opp-hz = /bits/ 64 <1608000000>; opp-microvolt = <787500 787500 950000>; clock-latency-ns = <40000>; }; - opp-1800000000 { - opp-hz = /bits/ 64 <1800000000>; - opp-microvolt = <875000 875000 950000>; - clock-latency-ns = <40000>; - }; - opp-2016000000 { - opp-hz = /bits/ 64 <2016000000>; - opp-microvolt = <950000 950000 950000>; - clock-latency-ns = <40000>; - }; }; gpu_opp_table: opp-table { @@ -104,10 +89,6 @@ opp-700000000 { opp-hz = /bits/ 64 <700000000>; opp-microvolt = <750000 750000 850000>; }; - opp-850000000 { - opp-hz = /bits/ 64 <800000000>; - opp-microvolt = <787500 787500 850000>; - }; }; };

5 months, 1 week

3
3
0 0

[RESEND PATCH] powerpc64/bpf: fix JIT code size calculation of bpf trampoline

by Hari Bathini

The JIT compile of ldimm instructions can be anywhere between 1-5 instructions long depending on the value being loaded. arch_bpf_trampoline_size() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. BPF trampoline JIT code has ldimm instructions that need to load the value of pointer to struct bpf_tramp_image. But this pointer value is not same while calling arch_bpf_trampoline_size() & arch_prepare_bpf_trampoline(). So, the size arrived at using arch_bpf_trampoline_size() can vary from the size needed in arch_prepare_bpf_trampoline(). When the number of ldimm instructions emitted in arch_bpf_trampoline_size() is less than the number of ldimm instructions emitted during the actual JIT compile of trampoline, the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc which is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { Pass NULL as the first argument to __arch_prepare_bpf_trampoline() call from arch_bpf_trampoline_size() function, to differentiate it from how arch_prepare_bpf_trampoline() calls it and ensure maximum possible instructions are emitted in arch_bpf_trampoline_size() for ldimm instructions that load a different value during the actual JIT compile of BPF trampoline. Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Reported-by: Venkat Rao Bagalkote <venkat88(a)linux.ibm.com> Closes: https://lore.kernel.org/all/6168bfc8-659f-4b5a-a6fb-90a916dde3b3@linux.ibm.… Cc: stable(a)vger.kernel.org # v6.13+ Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- * Removed a redundant '/' accidently added in a comment and resending. arch/powerpc/net/bpf_jit_comp.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c index 2991bb171a9b..c94717ccb2bd 100644 --- a/arch/powerpc/net/bpf_jit_comp.c +++ b/arch/powerpc/net/bpf_jit_comp.c @@ -833,7 +833,12 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im EMIT(PPC_RAW_STL(_R26, _R1, nvr_off + SZL)); if (flags & BPF_TRAMP_F_CALL_ORIG) { - PPC_LI_ADDR(_R3, (unsigned long)im); + /* + * Emit maximum possible instructions while getting the size of + * bpf trampoline to ensure trampoline JIT code doesn't overflow. + */ + PPC_LI_ADDR(_R3, im ? (unsigned long)im : + (unsigned long)(~(1UL << (BITS_PER_LONG - 1)))); ret = bpf_jit_emit_func_call_rel(image, ro_image, ctx, (unsigned long)__bpf_tramp_enter); if (ret) @@ -889,7 +894,8 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im bpf_trampoline_restore_tail_call_cnt(image, ctx, func_frame_offset, r4_off); /* Reserve space to patch branch instruction to skip fexit progs */ - im->ip_after_call = &((u32 *)ro_image)[ctx->idx]; + if (im) + im->ip_after_call = &((u32 *)ro_image)[ctx->idx]; EMIT(PPC_RAW_NOP()); } @@ -912,8 +918,14 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im } if (flags & BPF_TRAMP_F_CALL_ORIG) { - im->ip_epilogue = &((u32 *)ro_image)[ctx->idx]; - PPC_LI_ADDR(_R3, im); + if (im) + im->ip_epilogue = &((u32 *)ro_image)[ctx->idx]; + /* + * Emit maximum possible instructions while getting the size of + * bpf trampoline to ensure trampoline JIT code doesn't overflow. + */ + PPC_LI_ADDR(_R3, im ? (unsigned long)im : + (unsigned long)(~(1UL << (BITS_PER_LONG - 1)))); ret = bpf_jit_emit_func_call_rel(image, ro_image, ctx, (unsigned long)__bpf_tramp_exit); if (ret) @@ -972,7 +984,6 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags, struct bpf_tramp_links *tlinks, void *func_addr) { - struct bpf_tramp_image im; void *image; int ret; @@ -988,7 +999,13 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags, if (!image) return -ENOMEM; - ret = __arch_prepare_bpf_trampoline(&im, image, image + PAGE_SIZE, image, + /* + * Pass NULL as bpf_tramp_image pointer to differentiate the intent to get the + * buffer size for trampoline here. This differentiation helps in accounting for + * maximum possible instructions if the JIT code size is likely to vary during + * the actual JIT compile of the trampoline. + */ + ret = __arch_prepare_bpf_trampoline(NULL, image, image + PAGE_SIZE, image, m, flags, tlinks, func_addr); bpf_jit_free_exec(image); -- 2.48.1

5 months, 1 week

3
3
0 0

[PATCH] dmaengine: ti: k3-udma: Add missing locking

by Ronald Wahl

From: Ronald Wahl <ronald.wahl(a)legrand.com> Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled: [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking. Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA") Cc: Peter Ujfalusi <peter.ujfalusi(a)gmail.com> Cc: Vignesh Raghavendra <vigneshr(a)ti.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Ronald Wahl <ronald.wahl(a)legrand.com> --- drivers/dma/ti/k3-udma.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c index b3f27b3f9209..b9e497e8134b 100644 --- a/drivers/dma/ti/k3-udma.c +++ b/drivers/dma/ti/k3-udma.c @@ -1091,8 +1091,11 @@ static void udma_check_tx_completion(struct work_struct *work) u32 residue_diff; ktime_t time_diff; unsigned long delay; + unsigned long flags; while (1) { + spin_lock_irqsave(&uc->vc.lock, flags); + if (uc->desc) { /* Get previous residue and time stamp */ residue_diff = uc->tx_drain.residue; @@ -1127,6 +1130,8 @@ static void udma_check_tx_completion(struct work_struct *work) break; } + spin_unlock_irqrestore(&uc->vc.lock, flags); + usleep_range(ktime_to_us(delay), ktime_to_us(delay) + 10); continue; @@ -1143,6 +1148,8 @@ static void udma_check_tx_completion(struct work_struct *work) break; } + + spin_unlock_irqrestore(&uc->vc.lock, flags); } static irqreturn_t udma_ring_irq_handler(int irq, void *data) -- 2.48.0

5 months, 2 weeks

3
2
0 0

[PATCH stable] xdp: Reset bpf_redirect_info before running a xdp's BPF prog.

by Sebastian Andrzej Siewior

Ricardo reported a KASAN discovered use after free in v6.6-stable. The syzbot starts a BPF program via xdp_test_run_batch() which assigns ri->tgt_value via dev_hash_map_redirect() and the return code isn't XDP_REDIRECT it looks like nonsense. So the output in bpf_warn_invalid_xdp_action() appears once. Then the TUN driver runs another BPF program (on the same CPU) which returns XDP_REDIRECT without setting ri->tgt_value first. It invokes bpf_trace_printk() to print four characters and obtain the required return value. This is enough to get xdp_do_redirect() invoked which then accesses the pointer in tgt_value which might have been already deallocated. This problem does not affect upstream because since commit 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the per-CPU variable is referenced via task's task_struct and exists on the stack during NAPI callback. Therefore it is cleared once before the first invocation and remains valid within the RCU section of the NAPI callback. Instead of performing the huge backport of the commit (plus its fix ups) here is an alternative version which only resets the variable in question prior invoking the BPF program. Acked-by: Toke Høiland-Jørgensen <toke(a)kernel.org> Reported-by: Ricardo Cañuelo Navarro <rcn(a)igalia.com> Closes: https://lore.kernel.org/all/20250226-20250204-kasan-slab-use-after-free-rea… Fixes: 97f91a7cf04ff ("bpf: add bpf_redirect_map helper routine") Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> --- I discussed this with Toke, thread starts at https://lore.kernel.org/all/20250313183911.SPAmGLyw@linutronix.de/ The commit, which this by accident, is part of v6.11-rc1. I added the commit introducing map redirects as the origin of the problem which is v4.14-rc1. The code is a bit different there it seems to work similar. Greg, feel free to decide if this is worth a CVE. include/net/xdp.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/net/xdp.h b/include/net/xdp.h index de08c8e0d1348..b39ac83618a55 100644 --- a/include/net/xdp.h +++ b/include/net/xdp.h @@ -486,7 +486,14 @@ static __always_inline u32 bpf_prog_run_xdp(const struct bpf_prog *prog, * under local_bh_disable(), which provides the needed RCU protection * for accessing map entries. */ - u32 act = __bpf_prog_run(prog, xdp, BPF_DISPATCHER_FUNC(xdp)); + struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info); + u32 act; + + if (ri->map_id || ri->map_type) { + ri->map_id = 0; + ri->map_type = BPF_MAP_TYPE_UNSPEC; + } + act = __bpf_prog_run(prog, xdp, BPF_DISPATCHER_FUNC(xdp)); if (static_branch_unlikely(&bpf_master_redirect_enabled_key)) { if (act == XDP_TX && netif_is_bond_slave(xdp->rxq->dev)) -- 2.49.0

5 months, 2 weeks

2
3
0 0

[PATCH] loop: Properly send KOBJ_CHANGED uevent for disk device

by Thomas Weißschuh

The wording "uncork" in the code comment indicates that it is expected that the suppressed event instances are automatically sent after unsuppressing. This is not the case, they are discarded. In effect this means that no "changed" events are emitted on the device itself by default. On the other hand each discovered partition does trigger a "changed" event on the loop device itself. Therefore no event is emitted for devices without partitions. This leads to udev missing the device creation and prompting workarounds in userspace, see the linked util-linux/losetup bug. Explicitly emit the events and drop the confusingly worded comments. Link: https://github.com/util-linux/util-linux/issues/2434 Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- drivers/block/loop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index c05fe27a96b64f1f1ea3868510fdd0c7f4937f55..fbc67ff29e07c15f2e3b3e225a4a37df016fe9de 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -654,8 +654,8 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev, error = 0; done: - /* enable and uncork uevent now that we are done */ dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); + kobject_uevent(&disk_to_dev(lo->lo_disk)->kobj, KOBJ_CHANGE); return error; out_err: @@ -1115,8 +1115,8 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode, if (partscan) clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); - /* enable and uncork uevent now that we are done */ dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); + kobject_uevent(&disk_to_dev(lo->lo_disk)->kobj, KOBJ_CHANGE); loop_global_unlock(lo, is_loop); if (partscan) --- base-commit: 4701f33a10702d5fc577c32434eb62adde0a1ae1 change-id: 20250307-loop-uevent-changed-aa3690f43e03 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

5 months, 2 weeks

2
2
0 0

[PATCH v4 1/2] string: Add load_unaligned_zeropad() code path to sized_strscpy()

by Peter Collingbourne

The call to read_word_at_a_time() in sized_strscpy() is problematic with MTE because it may trigger a tag check fault when reading across a tag granule (16 bytes) boundary. To make this code MTE compatible, let's start using load_unaligned_zeropad() on architectures where it is available (i.e. architectures that define CONFIG_DCACHE_WORD_ACCESS). Because load_unaligned_zeropad() takes care of page boundaries as well as tag granule boundaries, also disable the code preventing crossing page boundaries when using load_unaligned_zeropad(). Signed-off-by: Peter Collingbourne <pcc(a)google.com> Link: https://linux-review.googlesource.com/id/If4b22e43b5a4ca49726b4bf98ada827fd… Fixes: 94ab5b61ee16 ("kasan, arm64: enable CONFIG_KASAN_HW_TAGS") Cc: stable(a)vger.kernel.org --- v2: - new approach lib/string.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/lib/string.c b/lib/string.c index eb4486ed40d25..b632c71df1a50 100644 --- a/lib/string.c +++ b/lib/string.c @@ -119,6 +119,7 @@ ssize_t sized_strscpy(char *dest, const char *src, size_t count) if (count == 0 || WARN_ON_ONCE(count > INT_MAX)) return -E2BIG; +#ifndef CONFIG_DCACHE_WORD_ACCESS #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS /* * If src is unaligned, don't cross a page boundary, @@ -133,12 +134,14 @@ ssize_t sized_strscpy(char *dest, const char *src, size_t count) /* If src or dest is unaligned, don't do word-at-a-time. */ if (((long) dest | (long) src) & (sizeof(long) - 1)) max = 0; +#endif #endif /* - * read_word_at_a_time() below may read uninitialized bytes after the - * trailing zero and use them in comparisons. Disable this optimization - * under KMSAN to prevent false positive reports. + * load_unaligned_zeropad() or read_word_at_a_time() below may read + * uninitialized bytes after the trailing zero and use them in + * comparisons. Disable this optimization under KMSAN to prevent + * false positive reports. */ if (IS_ENABLED(CONFIG_KMSAN)) max = 0; @@ -146,7 +149,11 @@ ssize_t sized_strscpy(char *dest, const char *src, size_t count) while (max >= sizeof(unsigned long)) { unsigned long c, data; +#ifdef CONFIG_DCACHE_WORD_ACCESS + c = load_unaligned_zeropad(src+res); +#else c = read_word_at_a_time(src+res); +#endif if (has_zero(c, &data, &constants)) { data = prep_zero_mask(c, data, &constants); data = create_zero_mask(data); -- 2.49.0.472.ge94155a9ec-goog

5 months, 2 weeks

3
4
0 0

[PATCH v3 0/2] Add wcslen()

by Nathan Chancellor

Hi all, A recent LLVM change [1] introduces a call to wcslen() in fs/smb/client/smb2pdu.c through UniStrcat() via alloc_path_with_tree_prefix(). Similar to the bcmp() and stpcpy() additions that happened in 5f074f3e192f and 1e1b6d63d634, add wcslen() to fix the linkage failure. [1]: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27… --- Changes in v3: - During comment shuffle in patch 1, move to standard multi-line comment kernel style (Andy). Carry forward Andy's review. - Move nls_types.h include in string.c in patch 2 to a better place alphabetically (Andy). - Drop 'extern' from wcslen() declaration in string.h, as external linkage is the default for functions and the coding style explicitly forbids it (Andy). - Link to v2: https://lore.kernel.org/r/20250326-string-add-wcslen-for-llvm-opt-v2-0-d864… Changes in v2: - Refactor typedefs from nls.h into nls_types.h to make it safe to include in string.h, which may be included in many places throughout the kernel that may not like the other stuff nls.h brings in: https://lore.kernel.org/202503260611.MDurOUhF-lkp@intel.com/ - Drop libstub change due to the above change, as it is no longer necessary. - Move prototype shuffle of patch 2 into the patch that adds wcslen() (Andy) - Use new nls_types.h in string.{c,h} - Link to v1: https://lore.kernel.org/r/20250325-string-add-wcslen-for-llvm-opt-v1-0-b8f1… --- Nathan Chancellor (2): include: Move typedefs in nls.h to their own header lib/string.c: Add wcslen() include/linux/nls.h | 19 +------------------ include/linux/nls_types.h | 26 ++++++++++++++++++++++++++ include/linux/string.h | 2 ++ lib/string.c | 11 +++++++++++ 4 files changed, 40 insertions(+), 18 deletions(-) --- base-commit: 78ab93c78fb31c5dfe207318aa2b7bd4e41f8dba change-id: 20250324-string-add-wcslen-for-llvm-opt-705791db92c0 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

5 months, 2 weeks

2
3
0 0

[PATCH v2 0/7] ufs-exynos stability fixes for gs101

by Peter Griffin

Hi folks, This series fixes several stability issues with the upstream ufs-exynos driver, specifically for the gs101 SoC found in Pixel 6. The main fix is regarding the IO cache coherency setting and ensuring that it is correctly applied depending on if the dma-coherent property is specified in device tree. This fixes the UFS stability issues on gs101 and I would imagine will also fix issues on exynosauto platform that seems to have similar iocc shareability bits. Additionally the phy reference counting is fixed which allows module load/unload to work reliably and keeps the phy state machine in sync with the controller glue driver. regards, Peter Changes since v1: * Added patch for correct handling of iocc depedent on dma-coherent property * Rebased onto next-20250319 * Add a gs101 specific suspend hook (Bart) * Drop asserting GPIO_OUT in .exit() (Peter) * Remove superfluous blank line (Bart) * Update PRDT_PREFECT_EN to PRDT_PREFETCH_EN (Bart) * Update commit description for desctype type 3 (Eric) * https://lore.kernel.org/lkml/20250226220414.343659-1-peter.griffin@linaro.o… Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> --- Peter Griffin (7): scsi: ufs: exynos: ensure pre_link() executes before exynos_ufs_phy_init() scsi: ufs: exynos: move ufs shareability value to drvdata scsi: ufs: exynos: disable iocc if dma-coherent property isn't set scsi: ufs: exynos: ensure consistent phy reference counts scsi: ufs: exynos: Enable PRDT pre-fetching with UFSHCD_CAP_CRYPTO scsi: ufs: exynos: Move phy calls to .exit() callback scsi: ufs: exynos: gs101: put ufs device in reset on .suspend() drivers/ufs/host/ufs-exynos.c | 85 ++++++++++++++++++++++++++++++++----------- drivers/ufs/host/ufs-exynos.h | 6 ++- 2 files changed, 68 insertions(+), 23 deletions(-) --- base-commit: 433ccb6f2e879866b8601fcb1de14e316cdb0d39 change-id: 20250319-exynos-ufs-stability-fixes-e8da9862e3dc Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

5 months, 2 weeks

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025