Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

244 participants
124060 discussions

FAILED: patch "[PATCH] LoongArch: BPF: Don't override subprog's return value" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 60f3caff1492e5b8616b9578c4bedb5c0a88ed14 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025040845-repeater-uninvited-9d3b@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 60f3caff1492e5b8616b9578c4bedb5c0a88ed14 Mon Sep 17 00:00:00 2001 From: Hengqi Chen <hengqi.chen(a)gmail.com> Date: Sun, 30 Mar 2025 16:31:09 +0800 Subject: [PATCH] LoongArch: BPF: Don't override subprog's return value The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL). Cc: stable(a)vger.kernel.org Fixes: 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") Signed-off-by: Hengqi Chen <hengqi.chen(a)gmail.com> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c index a06bf89fed67..fa1500d4aa3e 100644 --- a/arch/loongarch/net/bpf_jit.c +++ b/arch/loongarch/net/bpf_jit.c @@ -907,7 +907,10 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext move_addr(ctx, t1, func_addr); emit_insn(ctx, jirl, LOONGARCH_GPR_RA, t1, 0); - move_reg(ctx, regmap[BPF_REG_0], LOONGARCH_GPR_A0); + + if (insn->src_reg != BPF_PSEUDO_CALL) + move_reg(ctx, regmap[BPF_REG_0], LOONGARCH_GPR_A0); + break; /* tail call */

9 months

Re: Patch "wifi: mac80211: remove debugfs dir for virtual monitor" has been added to the 6.13-stable tree

by Alexander Wetzel

On 4/7/25 17:25, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > wifi: mac80211: remove debugfs dir for virtual monitor > > to the 6.13-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > wifi-mac80211-remove-debugfs-dir-for-virtual-monitor.patch > and it can be found in the queue-6.13 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > The commit here is causing a sparse warning. Please always add commit 861d0445e72e ("wifi: mac80211: Fix sparse warning for monitor_sdata") when you backport this patch to avoid that. (So far I got the backport notification for 6.12 and 6.13.) It's also no big deal when you decide to not backport this patch. > > > commit 193bafe31a2a08b5631a98ecf148fa0d18e94b0d > Author: Alexander Wetzel <Alexander(a)wetzel-home.de> > Date: Tue Feb 4 17:42:40 2025 +0100 > > wifi: mac80211: remove debugfs dir for virtual monitor > > [ Upstream commit 646262c71aca87bb66945933abe4e620796d6c5a ] > > Don't call ieee80211_debugfs_recreate_netdev() for virtual monitor > interface when deleting it. > > The virtual monitor interface shouldn't have debugfs entries and trying > to update them will *create* them on deletion. > > And when the virtual monitor interface is created/destroyed multiple > times we'll get warnings about debugfs name conflicts. > > Signed-off-by: Alexander Wetzel <Alexander(a)wetzel-home.de> > Link: https://patch.msgid.link/20250204164240.370153-1-Alexander@wetzel-home.de > Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c > index 299d38e9e8630..2fc60e1e77a55 100644 > --- a/net/mac80211/driver-ops.c > +++ b/net/mac80211/driver-ops.c > @@ -116,8 +116,14 @@ void drv_remove_interface(struct ieee80211_local *local, > > sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER; > > - /* Remove driver debugfs entries */ > - ieee80211_debugfs_recreate_netdev(sdata, sdata->vif.valid_links); > + /* > + * Remove driver debugfs entries. > + * The virtual monitor interface doesn't get a debugfs > + * entry, so it's exempt here. > + */ > + if (sdata != local->monitor_sdata) > + ieee80211_debugfs_recreate_netdev(sdata, > + sdata->vif.valid_links); > > trace_drv_remove_interface(local, sdata); > local->ops->remove_interface(&local->hw, &sdata->vif); > diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c > index 806dffa48ef92..04b3626387309 100644 > --- a/net/mac80211/iface.c > +++ b/net/mac80211/iface.c > @@ -1212,16 +1212,17 @@ void ieee80211_del_virtual_monitor(struct ieee80211_local *local) > return; > } > > - RCU_INIT_POINTER(local->monitor_sdata, NULL); > - mutex_unlock(&local->iflist_mtx); > - > - synchronize_net(); > - > + clear_bit(SDATA_STATE_RUNNING, &sdata->state); > ieee80211_link_release_channel(&sdata->deflink); > > if (ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF)) > drv_remove_interface(local, sdata); > > + RCU_INIT_POINTER(local->monitor_sdata, NULL); > + mutex_unlock(&local->iflist_mtx); > + > + synchronize_net(); > + > kfree(sdata); > } >

9 months

[PATCH v7] staging: rtl8723bs: Add error handling for sd_read()

by Wentao Liang

The sdio_read32() calls sd_read(), but does not handle the error if sd_read() fails. This could lead to subsequent operations processing invalid data. A proper implementation can be found in sdio_readN(), which has an error handling for the sd_read(). Add error handling for the sd_read() to free tmpbuf and return error code if sd_read() fails. This ensure that the memcpy() is only performed when the read operation is successful. Since none of the callers check for the errors, there is no need to return the error code propagated from sd_read(). Returning SDIO_ERR_VAL32 might be a better choice, which is a specialized error code for SDIO. Another problem of returning propagated error code is that the error code is a s32 type value, which is not fit with the u32 type return value of the sdio_read32(). An practical option would be to go through all the callers and add error handling, which need to pass a pointer to u32 *val and return zero on success or negative on failure. It is not a better choice since will cost unnecessary effort on the error code. The other opion is to replace sd_read() by sd_read32(), which return an u32 type error code that can be directly used as the return value of sdio_read32(). But, it is also a bad choice to use sd_read32() in a alignment failed branch. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- v7: Fix error code and add patch explanation v6: Fix improper code to propagate error code v5: Fix error code v4: Add change log and fix error code v3: Add Cc flag v2: Change code to initialize val drivers/staging/rtl8723bs/hal/sdio_ops.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c b/drivers/staging/rtl8723bs/hal/sdio_ops.c index 21e9f1858745..d79d41727042 100644 --- a/drivers/staging/rtl8723bs/hal/sdio_ops.c +++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c @@ -185,7 +185,12 @@ static u32 sdio_read32(struct intf_hdl *intfhdl, u32 addr) return SDIO_ERR_VAL32; ftaddr &= ~(u16)0x3; - sd_read(intfhdl, ftaddr, 8, tmpbuf); + err = sd_read(intfhdl, ftaddr, 8, tmpbuf); + if (err) { + kfree(tmpbuf); + return SDIO_ERR_VAL32; + } + memcpy(&le_tmp, tmpbuf + shift, 4); val = le32_to_cpu(le_tmp); -- 2.42.0.windows.2

9 months

[PATCH v3] platform/x86: thinkpad-acpi: Add error check for tpacpi_check_quirks

by Wentao Liang

In tpacpi_battery_init(), the return value of tpacpi_check_quirks() needs to be checked. The battery should not be hooked if there is no matched battery information in quirk table. Add an error check and return -ENODEV immediately if the device fail the check. Fixes: 1a32ebb26ba9 ("platform/x86: thinkpad_acpi: Support battery quirk") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- v3: Fix error code v2: Fix double assignment error drivers/platform/x86/thinkpad_acpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 2cfb2ac3f465..ab538bf53716 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -9974,6 +9974,8 @@ static int __init tpacpi_battery_init(struct ibm_init_struct *ibm) tp_features.battery_force_primary = tpacpi_check_quirks( battery_quirk_table, ARRAY_SIZE(battery_quirk_table)); + if (!tp_features.battery_force_primary) + return -ENODEV; battery_hook_register(&battery_hook); return 0; -- 2.42.0.windows.2

9 months

[PATCH 6.6.y] drm/amd/display: Check link_index before accessing dc->links[]

by jianqi.ren.cn＠windriver.com

From: Alex Hung <alex.hung(a)amd.com> [ Upstream commit 8aa2864044b9d13e95fe224f32e808afbf79ecdf ] [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index. This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [The macro MAX_LINKS is introduced by Commit 60df5628144b ("drm/amd/display: handle invalid connector indices") after 6.10. So here we still use the original array length MAX_PIPES * 2] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Verified the build test --- drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c index f365773d5714..e9b3c1c7a931 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c @@ -37,6 +37,9 @@ #include "dce/dce_i2c.h" struct dc_link *dc_get_link_at_index(struct dc *dc, uint32_t link_index) { + if (link_index >= (MAX_PIPES * 2)) + return NULL; + return dc->links[link_index]; } -- 2.34.1

9 months

[PATCH 5.15.y] drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration

by jianqi.ren.cn＠windriver.com

From: Hersen Wu <hersenxs.wu(a)amd.com> [ Upstream commit a54f7e866cc73a4cb71b8b24bb568ba35c8969df ] [Why] Coverity reports Memory - illegal accesses. [How] Skip inactive planes. Reviewed-by: Alex Hung <alex.hung(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Hersen Wu <hersenxs.wu(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [get_pipe_idx() was introduced as a helper by dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321") in v6.0. This patch backports it to make code clearer. And minor conflict is resolved due to code context change.] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Verified the build test --- .../drm/amd/display/dc/dml/display_mode_vba.c | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c b/drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c index 0fad15020c74..2beca0b06925 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c +++ b/drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c @@ -867,11 +867,30 @@ static unsigned int CursorBppEnumToBits(enum cursor_bpp ebpp) } } +static unsigned int get_pipe_idx(struct display_mode_lib *mode_lib, unsigned int plane_idx) +{ + int pipe_idx = -1; + int i; + + ASSERT(plane_idx < DC__NUM_DPP__MAX); + + for (i = 0; i < DC__NUM_DPP__MAX ; i++) { + if (plane_idx == mode_lib->vba.pipe_plane[i]) { + pipe_idx = i; + break; + } + } + ASSERT(pipe_idx >= 0); + + return pipe_idx; +} + void ModeSupportAndSystemConfiguration(struct display_mode_lib *mode_lib) { soc_bounding_box_st *soc = &mode_lib->vba.soc; unsigned int k; unsigned int total_pipes = 0; + unsigned int pipe_idx = 0; mode_lib->vba.VoltageLevel = mode_lib->vba.cache_pipes[0].clks_cfg.voltage; mode_lib->vba.ReturnBW = mode_lib->vba.ReturnBWPerState[mode_lib->vba.VoltageLevel][mode_lib->vba.maxMpcComb]; @@ -892,6 +911,11 @@ void ModeSupportAndSystemConfiguration(struct display_mode_lib *mode_lib) // Total Available Pipes Support Check for (k = 0; k < mode_lib->vba.NumberOfActivePlanes; ++k) { + pipe_idx = get_pipe_idx(mode_lib, k); + if (pipe_idx == -1) { + ASSERT(0); + continue; // skip inactive planes + } total_pipes += mode_lib->vba.DPPPerPlane[k]; } ASSERT(total_pipes <= DC__NUM_DPP__MAX); -- 2.34.1

9 months

[RESEND Patch v2 1/3] maple_tree: Fix mt_destroy_walk() on root leaf node

by Wei Yang

On destroy, we should set each node dead. But current code miss this when the maple tree has only the root node. The reason is mt_destroy_walk() leverage mte_destroy_descend() to set node dead, but this is skipped since the only root node is a leaf. Fixes this by setting the node dead if it is a leaf. Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> CC: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: <stable(a)vger.kernel.org> --- v2: * move the operation into mt_destroy_walk() * adjust the title accordingly --- lib/maple_tree.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 4bd5a5be1440..0696e8d1c4e9 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -5284,6 +5284,7 @@ static void mt_destroy_walk(struct maple_enode *enode, struct maple_tree *mt, struct maple_enode *start; if (mte_is_leaf(enode)) { + mte_set_node_dead(enode); node->type = mte_node_type(enode); goto free_leaf; } -- 2.34.1

9 months

[PATCH] sched_ext: Use kvzalloc for large exit_dump allocation

by Breno Leitao

Replace kzalloc with kvzalloc for the exit_dump buffer allocation, which can require large contiguous memory (up to order=9) depending on the implementation. This change prevents allocation failures by allowing the system to fall back to vmalloc when contiguous memory allocation fails. Since this buffer is only used for debugging purposes, physical memory contiguity is not required, making vmalloc a suitable alternative. Cc: stable(a)vger.kernel.org Fixes: 07814a9439a3b0 ("sched_ext: Print debug dump after an error exit") Suggested-by: Rik van Riel <riel(a)surriel.com> Signed-off-by: Breno Leitao <leitao(a)debian.org> --- kernel/sched/ext.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c index 66bcd40a28ca1..c82725f9b0559 100644 --- a/kernel/sched/ext.c +++ b/kernel/sched/ext.c @@ -4639,7 +4639,7 @@ static struct scx_exit_info *alloc_exit_info(size_t exit_dump_len) ei->bt = kcalloc(SCX_EXIT_BT_LEN, sizeof(ei->bt[0]), GFP_KERNEL); ei->msg = kzalloc(SCX_EXIT_MSG_LEN, GFP_KERNEL); - ei->dump = kzalloc(exit_dump_len, GFP_KERNEL); + ei->dump = kvzalloc(exit_dump_len, GFP_KERNEL); if (!ei->bt || !ei->msg || !ei->dump) { free_exit_info(ei); --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250407-scx-11dbf94803c3 Best regards, -- Breno Leitao <leitao(a)debian.org>

9 months

Re: Patch "timekeeping: Fix possible inconsistencies in _COARSE clockids" has been added to the 6.14-stable tree

by Thomas Gleixner

On Mon, Apr 07 2025 at 10:07, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > timekeeping: Fix possible inconsistencies in _COARSE clockids > > to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > timekeeping-fix-possible-inconsistencies-in-_coarse-.patch > and it can be found in the queue-6.14 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. As I asked on the stable list already, please do not add that to any stable tree. It has been reverted in Linus tree and the problem will be fixed differently. Thanks, tglx

9 months

[PATCH AUTOSEL 5.4] sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP

by Sasha Levin

From: Oleg Nesterov <oleg(a)redhat.com> [ Upstream commit 975776841e689dd8ba36df9fa72ac3eca3c2957a ] kernel/sched/isolation.c obviously makes no sense without CONFIG_SMP, but the Kconfig entry we have right now: config CPU_ISOLATION bool "CPU isolation" depends on SMP || COMPILE_TEST allows the creation of pointless .config's which cause build failures. Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20250330134955.GA7910@redhat.com Closes: https://lore.kernel.org/oe-kbuild-all/202503260646.lrUqD3j5-lkp@intel.com/ Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index f641518f4ac5c..01beb047aff2f 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -559,7 +559,7 @@ endmenu # "CPU/Task time and stats accounting" config CPU_ISOLATION bool "CPU isolation" - depends on SMP || COMPILE_TEST + depends on SMP default y help Make sure that CPUs running critical tasks are not disturbed by -- 2.39.5

9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror