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

回复:6.12.50 regression: netem: cannot mix duplicating netems with other netems in tree.

by zyc zyc

Hello, Resend my last email without HTML. ---- zyc zyc <zyc199902(a)zohomail.cn> 在 Sat, 2025-11-29 18:57:01 写到：--- > Hello, maintainer > > I would like to report what appears to be a regression in 6.12.50 kernel release related to netem. > It rejects our configuration with the message: > Error: netem: cannot mix duplicating netems with other netems in tree. > > This breaks setups that previously worked correctly for many years. > > > Our team uses multiple netem qdiscs in the same HTB branch, arranged in a parallel fashion using a prio fan-out. Each branch of the prio qdisc has its own distinct netem instance with different duplication characteristics. > > This is used to emulate our production conditions where a single logical path fans out into two downstream segments, for example: > > two ECMP next hops with different misbehaviour characteristics, or > > > an HA firewall cluster where only one node is replaying frames, or > > > two LAG / ToR paths where one path intermittently duplicates packets. > > > In our environments, only a subset of flows are affected, and different downstream devices may cause different styles of duplication. > This regression breaks existing automated tests, training environments, and network simulation pipelines. > > I would be happy to provide our reproducer if needed. > > Thank you for your time and for maintaining Linux kernel. > > > > Best regards, > zyc > > >

14 hours, 45 minutes

2
5
0 0

[PATCH v2] media: uvcvideo: Fix support for V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX

by Ricardo Ribalda

The VIDIOC_G_EXT_CTRLS with which V4L2_CTRL_WHICH_(MIN|MAX)_VAL can only work for controls that have previously announced support for it. This patch fixes the following v4l2-compliance error: info: checking extended control 'User Controls' (0x00980001) fail: v4l2-test-controls.cpp(980): ret != EINVAL (got 13) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Fixes: 39d2c891c96e ("media: uvcvideo: support V4L2_CTRL_WHICH_MIN/MAX_VAL") Cc: stable(a)vger.kernel.org Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v2, Thanks Laurent: - Remove redundant ioctl check - CodeStyle - Link to v1: https://lore.kernel.org/r/20251028-uvc-fix-which-v1-1-a7e6b82672a3@chromium… --- drivers/media/usb/uvc/uvc_ctrl.c | 14 ++++++++++++-- drivers/media/usb/uvc/uvc_v4l2.c | 10 ++++++---- drivers/media/usb/uvc/uvcvideo.h | 2 +- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 2905505c240c060e5034ea12d33b59d5702f2e1f..2738ef74c7373b185b67611da57610fd0b442080 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1432,7 +1432,7 @@ static bool uvc_ctrl_is_readable(u32 which, struct uvc_control *ctrl, * auto_exposure=1, exposure_time_absolute=251. */ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl) { struct uvc_control_mapping *master_map = NULL; @@ -1442,14 +1442,24 @@ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, s32 val; int ret; int i; + /* + * There is no need to check the ioctl, all the ioctls except + * VIDIOC_G_EXT_CTRLS use which=V4L2_CTRL_WHICH_CUR_VAL. + */ + bool is_which_min_max = which == V4L2_CTRL_WHICH_MIN_VAL || + which == V4L2_CTRL_WHICH_MAX_VAL; if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >= 0) - return -EACCES; + return is_which_min_max ? -EINVAL : -EACCES; ctrl = uvc_find_control(chain, v4l2_id, &mapping); if (!ctrl) return -EINVAL; + if ((!(ctrl->info.flags & UVC_CTRL_FLAG_GET_MIN) || + !(ctrl->info.flags & UVC_CTRL_FLAG_GET_MAX)) && is_which_min_max) + return -EINVAL; + if (ioctl == VIDIOC_G_EXT_CTRLS) return uvc_ctrl_is_readable(ctrls->which, ctrl, mapping); diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 9e4a251eca88085a1b4e0e854370015855be92ee..30c160daed8cb057b31ec00d665107dfdf4be1dc 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -765,14 +765,15 @@ static int uvc_ioctl_query_ext_ctrl(struct file *file, void *priv, static int uvc_ctrl_check_access(struct uvc_video_chain *chain, struct v4l2_ext_controls *ctrls, - unsigned long ioctl) + u32 which, unsigned long ioctl) { struct v4l2_ext_control *ctrl = ctrls->controls; unsigned int i; int ret = 0; for (i = 0; i < ctrls->count; ++ctrl, ++i) { - ret = uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, ioctl); + ret = uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, which, + ioctl); if (ret) break; } @@ -806,7 +807,7 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file, void *priv, which = V4L2_CTRL_WHICH_CUR_VAL; } - ret = uvc_ctrl_check_access(chain, ctrls, VIDIOC_G_EXT_CTRLS); + ret = uvc_ctrl_check_access(chain, ctrls, which, VIDIOC_G_EXT_CTRLS); if (ret < 0) return ret; @@ -840,7 +841,8 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh *handle, if (!ctrls->count) return 0; - ret = uvc_ctrl_check_access(chain, ctrls, ioctl); + ret = uvc_ctrl_check_access(chain, ctrls, V4L2_CTRL_WHICH_CUR_VAL, + ioctl); if (ret < 0) return ret; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index ed7bad31f75ca474c1037d666d5310c78dd764df..d583425893a5f716185153a07aae9bfe20182964 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -786,7 +786,7 @@ int uvc_ctrl_get(struct uvc_video_chain *chain, u32 which, struct v4l2_ext_control *xctrl); int uvc_ctrl_set(struct uvc_fh *handle, struct v4l2_ext_control *xctrl); int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl); int uvc_xu_ctrl_query(struct uvc_video_chain *chain, --- base-commit: c218ce4f98eccf5a40de64c559c52d61e9cc78ee change-id: 20251028-uvc-fix-which-c3ba1fb68ed5 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

14 hours, 52 minutes

2
1
0 0

[PATCH] ASoC: cs35l41: Always return 0 when a subsystem ID is found

by Eric Naim

When trying to get the system name in the _HID path, after successfully retrieving the subsystem ID the return value isn't set to 0 but instead still kept at -ENODATA, leading to a false negative: [ 12.382507] cs35l41 spi-VLV1776:00: Subsystem ID: VLV1776 [ 12.382521] cs35l41 spi-VLV1776:00: probe with driver cs35l41 failed with error -61 Always return 0 when a subsystem ID is found to mitigate these false negatives. Link: https://github.com/CachyOS/CachyOS-Handheld/issues/83 Fixes: 46c8b4d2a693 ("ASoC: cs35l41: Fallback to reading Subsystem ID property if not ACPI") Cc: stable(a)vger.kernel.org # 6.18 Signed-off-by: Eric Naim <dnaim(a)cachyos.org> --- sound/soc/codecs/cs35l41.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c index 173d7c59b725..5001a546a3e7 100644 --- a/sound/soc/codecs/cs35l41.c +++ b/sound/soc/codecs/cs35l41.c @@ -1188,13 +1188,14 @@ static int cs35l41_get_system_name(struct cs35l41_private *cs35l41) } } -err: if (sub) { cs35l41->dsp.system_name = sub; dev_info(cs35l41->dev, "Subsystem ID: %s\n", cs35l41->dsp.system_name); - } else - dev_warn(cs35l41->dev, "Subsystem ID not found\n"); + return 0; + } +err: + dev_warn(cs35l41->dev, "Subsystem ID not found\n"); return ret; } -- 2.52.0

15 hours, 13 minutes

2
1
0 0

[PATCH] staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure

by Liang Jie

From: Liang Jie <liangjie(a)lixiang.com> The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Cc: stable(a)vger.kernel.org Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Reviewed-by: fanggeng <fanggeng(a)lixiang.com> Signed-off-by: Liang Jie <liangjie(a)lixiang.com> --- drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c index f3caaa857c86..139ace51486d 100644 --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c @@ -377,7 +377,8 @@ static int rtw_drv_init( if (status != _SUCCESS) goto free_if1; - if (sdio_alloc_irq(dvobj) != _SUCCESS) + status = sdio_alloc_irq(dvobj); + if (status != _SUCCESS) goto free_if1; status = _SUCCESS; -- 2.25.1

15 hours, 17 minutes

1
0
0 0

[PATCH 6.18 regression fix] dma-mapping: Fix DMA_BIT_MASK() macro being broken

by Hans de Goede

After commit a50f7456f853 ("dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope"), the DMA_BIT_MASK() macro is broken when passed non trivial statements for the value of 'n'. This is caused by the new version missing parenthesis around 'n' when evaluating 'n'. One example of this breakage is the IPU6 driver now crashing due to it getting DMA-addresses with address bit 32 set even though it has tried to set a 32 bit DMA mask. The IPU6 CSI2 engine has a DMA mask of either 31 or 32 bits depending on if it is in secure mode or not and it sets this masks like this: mmu_info->aperture_end = (dma_addr_t)DMA_BIT_MASK(isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE); So the 'n' argument here is "isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE" which gets expanded into: isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE - 1 With the -1 only being applied in the non secure case, causing the secure mode mask to be one 1 bit too large. Fixes: a50f7456f853 ("dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope") Cc: Sakari Ailus <sakari.ailus(a)linux.intel.com> Cc: James Clark <james.clark(a)linaro.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 2ceda49c609f..aa36a0d1d9df 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -90,7 +90,7 @@ */ #define DMA_MAPPING_ERROR (~(dma_addr_t)0) -#define DMA_BIT_MASK(n) GENMASK_ULL(n - 1, 0) +#define DMA_BIT_MASK(n) GENMASK_ULL((n) - 1, 0) struct dma_iova_state { dma_addr_t addr; -- 2.52.0

16 hours, 1 minute

4
3
0 0

[PATCH] reset: gpio: suppress bind attributes in sysfs

by Bartosz Golaszewski

This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)oss.qualcomm.com> --- drivers/reset/reset-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-gpio.c b/drivers/reset/reset-gpio.c index e5512b3b596b..626c4c639c15 100644 --- a/drivers/reset/reset-gpio.c +++ b/drivers/reset/reset-gpio.c @@ -111,6 +111,7 @@ static struct auxiliary_driver reset_gpio_driver = { .id_table = reset_gpio_ids, .driver = { .name = "reset-gpio", + .suppress_bind_attrs = true, }, }; module_auxiliary_driver(reset_gpio_driver); -- 2.51.0

17 hours, 29 minutes

3
5
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-deuce-arrange-e66c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

17 hours, 50 minutes

2
2
0 0

[PATCH] xfs: Fix a memory leak bug in xfs_buf_item_init()

by Haoxiang Li

xfs_buf_item_get_format() may allocate memory for bip->bli_formats, free the memory in the error path. Fixes: c3d5f0c2fb85 ("xfs: complain if anyone tries to create a too-large buffer log item") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- fs/xfs/xfs_buf_item.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index 8d85b5eee444..f4c5be67826e 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -896,6 +896,7 @@ xfs_buf_item_init( map_size = DIV_ROUND_UP(chunks, NBWORD); if (map_size > XFS_BLF_DATAMAP_SIZE) { + xfs_buf_item_free_format(bip); kmem_cache_free(xfs_buf_item_cache, bip); xfs_err(mp, "buffer item dirty bitmap (%u uints) too small to reflect %u bytes!", -- 2.25.1

17 hours, 55 minutes

2
1
0 0

Re: Patch "dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope" has been added to the 6.17-stable tree

by Nathan Chancellor

On Sun, Dec 07, 2025 at 10:07:49PM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > to the 6.17-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: > dma-mapping-allow-use-of-dma_bit_mask-64-in-global-s.patch > and it can be found in the queue-6.17 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. > > > > commit 51a1912d46ceb70602de50c167e440966b9836f1 > Author: James Clark <james.clark(a)linaro.org> > Date: Thu Oct 30 14:05:27 2025 +0000 > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > [ Upstream commit a50f7456f853ec3a6f07cbe1d16ad8a8b2501320 ] This change has a pending bug fix, consider waiting to apply this to the stable trees. https://lore.kernel.org/20251207184756.97904-1-johannes.goede@oss.qualcomm.… Cheers, Nathan

21 hours, 21 minutes

1
0
0 0

[STATUS] stable/linux-5.10.y - f964b940099f9982d723d4c77988d4b0dda9c165

by KernelCI bot

Hello, Status summary for stable/linux-5.10.y Dashboard: https://d.kernelci.org/c/stable/linux-5.10.y/f964b940099f9982d723d4c77988d4… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-5.10.y commit hash: f964b940099f9982d723d4c77988d4b0dda9c165 origin: maestro test start time: 2025-12-06 22:05:22.856000+00:00 Builds: 38 ✅ 0 ❌ 0 ⚠️ Boots: 69 ✅ 0 ❌ 0 ⚠️ Tests: 972 ✅ 267 ❌ 200 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS Hardware: beaglebone-black > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-14 - ltp last run: https://d.kernelci.org/test/maestro:6934ce3b1ca5bf9d0fd6c4d7 history: > ❌ > ❌ > ✅ > ✅ > ✅ ### UNSTABLE TESTS No unstable tests observed. Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

22 hours, 14 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror