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

[PATCH v2 RESEND] coresight: etm-perf: Fix reference count leak in etm_setup_aux

by Ma Ke

In etm_setup_aux(), when a user sink is obtained via coresight_get_sink_by_id(), it increments the reference count of the sink device. However, if the sink is used in path building, the path holds a reference, but the initial reference from coresight_get_sink_by_id() is not released, causing a reference count leak. We should release the initial reference after the path is built. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 0e6c20517596 ("coresight: etm-perf: Allow an event to use different sinks") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch as suggestions. --- drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index 17afa0f4cdee..56d012ab6d3a 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -454,6 +454,11 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, goto err; out: + if (user_sink) { + put_device(&user_sink->dev); + user_sink = NULL; + } + return event_data; err: -- 2.17.1

9 hours, 19 minutes

1
0
0 0

[PATCH v2] USB: Fix error handling in gadget driver

by Ma Ke

lpc32xx_udc_probe() acquires an i2c_client reference through isp1301_get_client() but fails to release it in both error handling paths and the normal removal path. This could result in a reference count leak for the I2C device, preventing proper cleanup and potentially leading to resource exhaustion. Add put_device() to release the reference in the probe failure path and in the remove function. Calling path: isp1301_get_client() -> of_find_i2c_device_by_node() -> i2c_find_device_by_fwnode(). As comments of i2c_find_device_by_fwnode() says, 'The user must call put_device(&client->dev) once done with the i2c client.' Found by code review. Cc: stable(a)vger.kernel.org Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - simplified the patch as suggestions. --- drivers/usb/gadget/udc/lpc32xx_udc.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index 1a7d3c4f652f..73c0f28a8585 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -3020,7 +3020,7 @@ static int lpc32xx_udc_probe(struct platform_device *pdev) pdev->dev.dma_mask = &lpc32xx_usbd_dmamask; retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (retval) - return retval; + goto i2c_fail; udc->board = &lpc32xx_usbddata; @@ -3038,28 +3038,32 @@ static int lpc32xx_udc_probe(struct platform_device *pdev) /* Get IRQs */ for (i = 0; i < 4; i++) { udc->udp_irq[i] = platform_get_irq(pdev, i); - if (udc->udp_irq[i] < 0) - return udc->udp_irq[i]; + if (udc->udp_irq[i] < 0) { + retval = udc->udp_irq[i]; + goto i2c_fail; + } } udc->udp_baseaddr = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(udc->udp_baseaddr)) { dev_err(udc->dev, "IO map failure\n"); - return PTR_ERR(udc->udp_baseaddr); + retval = PTR_ERR(udc->udp_baseaddr); + goto i2c_fail; } /* Get USB device clock */ udc->usb_slv_clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(udc->usb_slv_clk)) { dev_err(udc->dev, "failed to acquire USB device clock\n"); - return PTR_ERR(udc->usb_slv_clk); + retval = PTR_ERR(udc->usb_slv_clk); + goto i2c_fail; } /* Enable USB device clock */ retval = clk_prepare_enable(udc->usb_slv_clk); if (retval < 0) { dev_err(udc->dev, "failed to start USB device clock\n"); - return retval; + goto i2c_fail; } /* Setup deferred workqueue data */ @@ -3161,6 +3165,8 @@ static int lpc32xx_udc_probe(struct platform_device *pdev) dma_free_coherent(&pdev->dev, UDCA_BUFF_SIZE, udc->udca_v_base, udc->udca_p_base); i2c_fail: + if (udc->isp1301_i2c_client) + put_device(&udc->isp1301_i2c_client->dev); clk_disable_unprepare(udc->usb_slv_clk); dev_err(udc->dev, "%s probe failed, %d\n", driver_name, retval); @@ -3189,6 +3195,9 @@ static void lpc32xx_udc_remove(struct platform_device *pdev) dma_free_coherent(&pdev->dev, UDCA_BUFF_SIZE, udc->udca_v_base, udc->udca_p_base); + if (udc->isp1301_i2c_client) + put_device(&udc->isp1301_i2c_client->dev); + clk_disable_unprepare(udc->usb_slv_clk); } -- 2.17.1

9 hours, 48 minutes

1
0
0 0

[PATCH RESEND] dmaengine: ti-dma-crossbar: Fix error handling in ti_am335x_xbar_route_allocate

by Ma Ke

ti_am335x_xbar_route_allocate() calls of_find_device_by_node() which increments the reference count of the platform device, but fails to call put_device() to decrement the reference count before returning. This could cause a reference count leak each time the function is called, preventing the platform device from being properly cleaned up and leading to memory leakage. Add proper put_device() calls in all exit paths to fix the reference count imbalance. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 42dbdcc6bf96 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/dma/ti/dma-crossbar.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/dma/ti/dma-crossbar.c b/drivers/dma/ti/dma-crossbar.c index 7f17ee87a6dc..58bc515ec8b3 100644 --- a/drivers/dma/ti/dma-crossbar.c +++ b/drivers/dma/ti/dma-crossbar.c @@ -80,33 +80,40 @@ static void *ti_am335x_xbar_route_allocate(struct of_phandle_args *dma_spec, struct platform_device *pdev = of_find_device_by_node(ofdma->of_node); struct ti_am335x_xbar_data *xbar = platform_get_drvdata(pdev); struct ti_am335x_xbar_map *map; + int ret; - if (dma_spec->args_count != 3) - return ERR_PTR(-EINVAL); + if (dma_spec->args_count != 3) { + ret = -EINVAL; + goto err_put_device; + } if (dma_spec->args[2] >= xbar->xbar_events) { dev_err(&pdev->dev, "Invalid XBAR event number: %d\n", dma_spec->args[2]); - return ERR_PTR(-EINVAL); + ret = -EINVAL; + goto err_put_device; } if (dma_spec->args[0] >= xbar->dma_requests) { dev_err(&pdev->dev, "Invalid DMA request line number: %d\n", dma_spec->args[0]); - return ERR_PTR(-EINVAL); + ret = -EINVAL; + goto err_put_device; } /* The of_node_put() will be done in the core for the node */ dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0); if (!dma_spec->np) { dev_err(&pdev->dev, "Can't get DMA master\n"); - return ERR_PTR(-EINVAL); + ret = -EINVAL; + goto err_put_device; } map = kzalloc(sizeof(*map), GFP_KERNEL); if (!map) { of_node_put(dma_spec->np); - return ERR_PTR(-ENOMEM); + ret = -ENOMEM; + goto err_put_device; } map->dma_line = (u16)dma_spec->args[0]; @@ -120,7 +127,12 @@ static void *ti_am335x_xbar_route_allocate(struct of_phandle_args *dma_spec, ti_am335x_xbar_write(xbar->iomem, map->dma_line, map->mux_val); + put_device(&pdev->dev); return map; + +err_put_device: + put_device(&pdev->dev); + return ERR_PTR(ret); } static const struct of_device_id ti_am335x_master_match[] __maybe_unused = { -- 2.17.1

10 hours, 15 minutes

1
0
0 0

[PATCH] rpmsg: core: fix race in driver_override_show() and use core helper

by Gui-Dong Han

The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- I verified this with a stress test that continuously writes/reads the attribute. It triggered KASAN and leaked bytes like a0 f4 81 9f a3 ff ff (likely kernel pointers). Since driver_override is world-readable (0644), this allows unprivileged users to leak kernel pointers and bypass KASLR. Similar races were fixed in other buses (e.g., commits 9561475db680 and 91d44c1afc61). Currently, 9 of 11 buses handle this correctly; this patch fixes one of the remaining two. --- drivers/rpmsg/rpmsg_core.c | 66 ++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 39 deletions(-) diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c index 5d661681a9b6..96964745065b 100644 --- a/drivers/rpmsg/rpmsg_core.c +++ b/drivers/rpmsg/rpmsg_core.c @@ -352,50 +352,38 @@ field##_show(struct device *dev, \ } \ static DEVICE_ATTR_RO(field); -#define rpmsg_string_attr(field, member) \ -static ssize_t \ -field##_store(struct device *dev, struct device_attribute *attr, \ - const char *buf, size_t sz) \ -{ \ - struct rpmsg_device *rpdev = to_rpmsg_device(dev); \ - const char *old; \ - char *new; \ - \ - new = kstrndup(buf, sz, GFP_KERNEL); \ - if (!new) \ - return -ENOMEM; \ - new[strcspn(new, "\n")] = '\0'; \ - \ - device_lock(dev); \ - old = rpdev->member; \ - if (strlen(new)) { \ - rpdev->member = new; \ - } else { \ - kfree(new); \ - rpdev->member = NULL; \ - } \ - device_unlock(dev); \ - \ - kfree(old); \ - \ - return sz; \ -} \ -static ssize_t \ -field##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - struct rpmsg_device *rpdev = to_rpmsg_device(dev); \ - \ - return sprintf(buf, "%s\n", rpdev->member); \ -} \ -static DEVICE_ATTR_RW(field) - /* for more info, see Documentation/ABI/testing/sysfs-bus-rpmsg */ rpmsg_show_attr(name, id.name, "%s\n"); rpmsg_show_attr(src, src, "0x%x\n"); rpmsg_show_attr(dst, dst, "0x%x\n"); rpmsg_show_attr(announce, announce ? "true" : "false", "%s\n"); -rpmsg_string_attr(driver_override, driver_override); + +static ssize_t driver_override_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct rpmsg_device *rpdev = to_rpmsg_device(dev); + int ret; + + ret = driver_set_override(dev, &rpdev->driver_override, buf, count); + if (ret) + return ret; + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct rpmsg_device *rpdev = to_rpmsg_device(dev); + ssize_t len; + + device_lock(dev); + len = sysfs_emit(buf, "%s\n", rpdev->driver_override); + device_unlock(dev); + return len; +} +static DEVICE_ATTR_RW(driver_override); static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, char *buf) -- 2.43.0

10 hours, 18 minutes

3
2
0 0

Re: Patch "RAS: Report all ARM processor CPER information to userspace" has been added to the 6.18-stable tree

by Mauro Carvalho Chehab

Hi Sacha, Em Sat, 13 Dec 2025 04:49:42 -0500 Sasha Levin <sashal(a)kernel.org> escreveu: > This is a note to let you know that I've just added the patch titled > > RAS: Report all ARM processor CPER information to userspace > > to the 6.18-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: > ras-report-all-arm-processor-cper-information-to-use.patch > and it can be found in the queue-6.18 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. You should also backport this patch(*): 96b010536ee0 efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs It fixes a bug at the UEFI parser for the ARM Processor Error record: basically, the specs were not clear about how the error type should be reported. The Kernel implementation were assuming that this was an enum, but UEFI errata 2.9A make it clear that the value is a bitmap. So, basically, all kernels up to 6.18 are not parsing the field the expected way: only "Cache error" was properly reported. The other 3 types were wrong. (*) You could need to backport those patches as well: a976d790f494 efi/cper: Add a new helper function to print bitmasks 8ad2c72e21ef efi/cper: Adjust infopfx size to accept an extra space Regards, Mauro Thanks, Mauro

10 hours, 20 minutes

2
1
0 0

Re: Patch "block: fix cached zone reports on devices with native zone append" has been added to the 6.18-stable tree

by Damien Le Moal

On 12/15/25 09:37, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > block: fix cached zone reports on devices with native zone append > > to the 6.18-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: > block-fix-cached-zone-reports-on-devices-with-native.patch > and it can be found in the queue-6.18 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. Sasha, This is a fix for a new feature that was queued for and is now added to 6.19. So backporting this to stable and LTS kernels is not advisable. -- Damien Le Moal Western Digital Research

10 hours, 20 minutes

2
2
0 0

Re: Patch "block: mq-deadline: Remove support for zone write locking" has been added to the 6.6-stable tree

by Damien Le Moal

On 12/13/25 20:09, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > block: mq-deadline: Remove support for zone write locking > > to the 6.6-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: > block-mq-deadline-remove-support-for-zone-write-lock.patch > and it can be found in the queue-6.6 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. Sasha, Zone write locking in the mq-deadline scheduler was replaced with the generic zone write plugging in the block layer in 6.10. That was not backported as that is a new feature. So removing zone write locking in 6.6 will break support for SMR drives and other zoned block devices. Removing it from 6.6 is thus not OK. Please undo this. > commit bf2022eaa2291ad1243b0711d5bd03ba4105ffbb > Author: Damien Le Moal <dlemoal(a)kernel.org> > Date: Mon Apr 8 10:41:21 2024 +0900 > > block: mq-deadline: Remove support for zone write locking > > [ Upstream commit fde02699c242e88a71286677d27cc890a959b67f ] > > With the block layer generic plugging of write operations for zoned > block devices, mq-deadline, or any other scheduler, can only ever > see at most one write operation per zone at any time. There is thus no > sequentiality requirements for these writes and thus no need to tightly > control the dispatching of write requests using zone write locking. > > Remove all the code that implement this control in the mq-deadline > scheduler and remove advertizing support for the > ELEVATOR_F_ZBD_SEQ_WRITE elevator feature. > > Signed-off-by: Damien Le Moal <dlemoal(a)kernel.org> > Reviewed-by: Hannes Reinecke <hare(a)suse.de> > Reviewed-by: Christoph Hellwig <hch(a)lst.de> > Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> > Tested-by: Hans Holmberg <hans.holmberg(a)wdc.com> > Tested-by: Dennis Maisenbacher <dennis.maisenbacher(a)wdc.com> > Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> > Link: https://lore.kernel.org/r/20240408014128.205141-22-dlemoal@kernel.org > Signed-off-by: Jens Axboe <axboe(a)kernel.dk> > Stable-dep-of: d60055cf5270 ("block/mq-deadline: Switch back to a single dispatch list") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/block/mq-deadline.c b/block/mq-deadline.c > index 78a8aa204c156..23638b03d7b3d 100644 > --- a/block/mq-deadline.c > +++ b/block/mq-deadline.c > @@ -102,7 +102,6 @@ struct deadline_data { > int prio_aging_expire; > > spinlock_t lock; > - spinlock_t zone_lock; > }; > > /* Maps an I/O priority class to a deadline scheduler priority. */ > @@ -157,8 +156,7 @@ deadline_latter_request(struct request *rq) > } > > /* > - * Return the first request for which blk_rq_pos() >= @pos. For zoned devices, > - * return the first request after the start of the zone containing @pos. > + * Return the first request for which blk_rq_pos() >= @pos. > */ > static inline struct request *deadline_from_pos(struct dd_per_prio *per_prio, > enum dd_data_dir data_dir, sector_t pos) > @@ -170,14 +168,6 @@ static inline struct request *deadline_from_pos(struct dd_per_prio *per_prio, > return NULL; > > rq = rb_entry_rq(node); > - /* > - * A zoned write may have been requeued with a starting position that > - * is below that of the most recently dispatched request. Hence, for > - * zoned writes, start searching from the start of a zone. > - */ > - if (blk_rq_is_seq_zoned_write(rq)) > - pos = round_down(pos, rq->q->limits.chunk_sectors); > - > while (node) { > rq = rb_entry_rq(node); > if (blk_rq_pos(rq) >= pos) { > @@ -308,36 +298,6 @@ static inline bool deadline_check_fifo(struct dd_per_prio *per_prio, > return time_is_before_eq_jiffies((unsigned long)rq->fifo_time); > } > > -/* > - * Check if rq has a sequential request preceding it. > - */ > -static bool deadline_is_seq_write(struct deadline_data *dd, struct request *rq) > -{ > - struct request *prev = deadline_earlier_request(rq); > - > - if (!prev) > - return false; > - > - return blk_rq_pos(prev) + blk_rq_sectors(prev) == blk_rq_pos(rq); > -} > - > -/* > - * Skip all write requests that are sequential from @rq, even if we cross > - * a zone boundary. > - */ > -static struct request *deadline_skip_seq_writes(struct deadline_data *dd, > - struct request *rq) > -{ > - sector_t pos = blk_rq_pos(rq); > - > - do { > - pos += blk_rq_sectors(rq); > - rq = deadline_latter_request(rq); > - } while (rq && blk_rq_pos(rq) == pos); > - > - return rq; > -} > - > /* > * For the specified data direction, return the next request to > * dispatch using arrival ordered lists. > @@ -346,40 +306,10 @@ static struct request * > deadline_fifo_request(struct deadline_data *dd, struct dd_per_prio *per_prio, > enum dd_data_dir data_dir) > { > - struct request *rq, *rb_rq, *next; > - unsigned long flags; > - > if (list_empty(&per_prio->fifo_list[data_dir])) > return NULL; > > - rq = rq_entry_fifo(per_prio->fifo_list[data_dir].next); > - if (data_dir == DD_READ || !blk_queue_is_zoned(rq->q)) > - return rq; > - > - /* > - * Look for a write request that can be dispatched, that is one with > - * an unlocked target zone. For some HDDs, breaking a sequential > - * write stream can lead to lower throughput, so make sure to preserve > - * sequential write streams, even if that stream crosses into the next > - * zones and these zones are unlocked. > - */ > - spin_lock_irqsave(&dd->zone_lock, flags); > - list_for_each_entry_safe(rq, next, &per_prio->fifo_list[DD_WRITE], > - queuelist) { > - /* Check whether a prior request exists for the same zone. */ > - rb_rq = deadline_from_pos(per_prio, data_dir, blk_rq_pos(rq)); > - if (rb_rq && blk_rq_pos(rb_rq) < blk_rq_pos(rq)) > - rq = rb_rq; > - if (blk_req_can_dispatch_to_zone(rq) && > - (blk_queue_nonrot(rq->q) || > - !deadline_is_seq_write(dd, rq))) > - goto out; > - } > - rq = NULL; > -out: > - spin_unlock_irqrestore(&dd->zone_lock, flags); > - > - return rq; > + return rq_entry_fifo(per_prio->fifo_list[data_dir].next); > } > > /* > @@ -390,36 +320,8 @@ static struct request * > deadline_next_request(struct deadline_data *dd, struct dd_per_prio *per_prio, > enum dd_data_dir data_dir) > { > - struct request *rq; > - unsigned long flags; > - > - rq = deadline_from_pos(per_prio, data_dir, > - per_prio->latest_pos[data_dir]); > - if (!rq) > - return NULL; > - > - if (data_dir == DD_READ || !blk_queue_is_zoned(rq->q)) > - return rq; > - > - /* > - * Look for a write request that can be dispatched, that is one with > - * an unlocked target zone. For some HDDs, breaking a sequential > - * write stream can lead to lower throughput, so make sure to preserve > - * sequential write streams, even if that stream crosses into the next > - * zones and these zones are unlocked. > - */ > - spin_lock_irqsave(&dd->zone_lock, flags); > - while (rq) { > - if (blk_req_can_dispatch_to_zone(rq)) > - break; > - if (blk_queue_nonrot(rq->q)) > - rq = deadline_latter_request(rq); > - else > - rq = deadline_skip_seq_writes(dd, rq); > - } > - spin_unlock_irqrestore(&dd->zone_lock, flags); > - > - return rq; > + return deadline_from_pos(per_prio, data_dir, > + per_prio->latest_pos[data_dir]); > } > > /* > @@ -525,10 +427,6 @@ static struct request *__dd_dispatch_request(struct deadline_data *dd, > rq = next_rq; > } > > - /* > - * For a zoned block device, if we only have writes queued and none of > - * them can be dispatched, rq will be NULL. > - */ > if (!rq) > return NULL; > > @@ -549,10 +447,6 @@ static struct request *__dd_dispatch_request(struct deadline_data *dd, > prio = ioprio_class_to_prio[ioprio_class]; > dd->per_prio[prio].latest_pos[data_dir] = blk_rq_pos(rq); > dd->per_prio[prio].stats.dispatched++; > - /* > - * If the request needs its target zone locked, do it. > - */ > - blk_req_zone_write_lock(rq); > rq->rq_flags |= RQF_STARTED; > return rq; > } > @@ -736,7 +630,6 @@ static int dd_init_sched(struct request_queue *q, struct elevator_type *e) > dd->fifo_batch = fifo_batch; > dd->prio_aging_expire = prio_aging_expire; > spin_lock_init(&dd->lock); > - spin_lock_init(&dd->zone_lock); > > /* We dispatch from request queue wide instead of hw queue */ > blk_queue_flag_set(QUEUE_FLAG_SQ_SCHED, q); > @@ -818,12 +711,6 @@ static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, > > lockdep_assert_held(&dd->lock); > > - /* > - * This may be a requeue of a write request that has locked its > - * target zone. If it is the case, this releases the zone lock. > - */ > - blk_req_zone_write_unlock(rq); > - > prio = ioprio_class_to_prio[ioprio_class]; > per_prio = &dd->per_prio[prio]; > if (!rq->elv.priv[0]) { > @@ -855,18 +742,6 @@ static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, > */ > rq->fifo_time = jiffies + dd->fifo_expire[data_dir]; > insert_before = &per_prio->fifo_list[data_dir]; > -#ifdef CONFIG_BLK_DEV_ZONED > - /* > - * Insert zoned writes such that requests are sorted by > - * position per zone. > - */ > - if (blk_rq_is_seq_zoned_write(rq)) { > - struct request *rq2 = deadline_latter_request(rq); > - > - if (rq2 && blk_rq_zone_no(rq2) == blk_rq_zone_no(rq)) > - insert_before = &rq2->queuelist; > - } > -#endif > list_add_tail(&rq->queuelist, insert_before); > } > } > @@ -901,33 +776,8 @@ static void dd_prepare_request(struct request *rq) > rq->elv.priv[0] = NULL; > } > > -static bool dd_has_write_work(struct blk_mq_hw_ctx *hctx) > -{ > - struct deadline_data *dd = hctx->queue->elevator->elevator_data; > - enum dd_prio p; > - > - for (p = 0; p <= DD_PRIO_MAX; p++) > - if (!list_empty_careful(&dd->per_prio[p].fifo_list[DD_WRITE])) > - return true; > - > - return false; > -} > - > /* > * Callback from inside blk_mq_free_request(). > - * > - * For zoned block devices, write unlock the target zone of > - * completed write requests. Do this while holding the zone lock > - * spinlock so that the zone is never unlocked while deadline_fifo_request() > - * or deadline_next_request() are executing. This function is called for > - * all requests, whether or not these requests complete successfully. > - * > - * For a zoned block device, __dd_dispatch_request() may have stopped > - * dispatching requests if all the queued requests are write requests directed > - * at zones that are already locked due to on-going write requests. To ensure > - * write request dispatch progress in this case, mark the queue as needing a > - * restart to ensure that the queue is run again after completion of the > - * request and zones being unlocked. > */ > static void dd_finish_request(struct request *rq) > { > @@ -942,21 +792,8 @@ static void dd_finish_request(struct request *rq) > * called dd_insert_requests(). Skip requests that bypassed I/O > * scheduling. See also blk_mq_request_bypass_insert(). > */ > - if (!rq->elv.priv[0]) > - return; > - > - atomic_inc(&per_prio->stats.completed); > - > - if (blk_queue_is_zoned(q)) { > - unsigned long flags; > - > - spin_lock_irqsave(&dd->zone_lock, flags); > - blk_req_zone_write_unlock(rq); > - spin_unlock_irqrestore(&dd->zone_lock, flags); > - > - if (dd_has_write_work(rq->mq_hctx)) > - blk_mq_sched_mark_restart_hctx(rq->mq_hctx); > - } > + if (rq->elv.priv[0]) > + atomic_inc(&per_prio->stats.completed); > } > > static bool dd_has_work_for_prio(struct dd_per_prio *per_prio) > @@ -1280,7 +1117,6 @@ static struct elevator_type mq_deadline = { > .elevator_attrs = deadline_attrs, > .elevator_name = "mq-deadline", > .elevator_alias = "deadline", > - .elevator_features = ELEVATOR_F_ZBD_SEQ_WRITE, > .elevator_owner = THIS_MODULE, > }; > MODULE_ALIAS("mq-deadline-iosched"); -- Damien Le Moal Western Digital Research

10 hours, 39 minutes

1
0
0 0

[PATCH AUTOSEL 6.18-6.17] ALSA: hda/realtek: Add support for ASUS UM3406GA

by Sasha Levin

From: Stefan Binding <sbinding(a)opensource.cirrus.com> [ Upstream commit 826c0b1ed09e5335abcae07292440ce72346e578 ] Laptops use 2 CS35L41 Amps with HDA, using External boost, with I2C Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> Link: https://patch.msgid.link/20251205150614.49590-3-sbinding@opensource.cirrus.… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Commit Analysis: ALSA: hda/realtek: Add support for ASUS UM3406GA ### 1. COMMIT MESSAGE ANALYSIS The commit message is straightforward: it adds support for a specific ASUS laptop model (UM3406GA) that uses 2 CS35L41 amplifiers connected via I2C with external boost. The message describes the hardware configuration, which is standard for such device ID additions. No Fixes: or Cc: stable tags are present, but as noted, this is expected for commits requiring manual review. ### 2. CODE CHANGE ANALYSIS The entire change is a single line addition: ```c SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), ``` This adds: - Vendor ID: 0x1043 (ASUS) - Device/Subsystem ID: 0x1584 (ASUS UM3406GA) - Fixup: `ALC287_FIXUP_CS35L41_I2C_2` (an **existing** fixup already used by many other ASUS models) Looking at the surrounding code, multiple other ASUS laptops use the same fixup: - ASUS PM3406CKA (0x1454) - ASUS G513PI/PU/PV (0x14e3) - ASUS G733PY/PZ/PZV/PYV (0x1503) - ASUS GV302XA/XJ/XQ/XU/XV/XI (0x1533) - ASUS UM3402YAR (0x1683) ### 3. CLASSIFICATION This is a **NEW DEVICE ID** addition - explicitly listed as an exception that IS appropriate for stable backporting. The driver infrastructure and fixup code already exist; this merely adds an ID to enable the existing fix for new hardware. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 1 line - **Files touched**: 1 file - **Complexity**: Zero - table entry addition only - **Risk**: Extremely low - this cannot affect any other hardware - **No new code paths**: Uses pre-existing `ALC287_FIXUP_CS35L41_I2C_2` fixup ### 5. USER IMPACT - **Who is affected**: Owners of ASUS UM3406GA laptops - **Problem without fix**: Audio (specifically the CS35L41 amplifiers) won't function properly - **Severity**: Non-working audio is a significant user-facing issue for laptop users ### 6. STABILITY INDICATORS - Signed-off by Takashi Iwai (ALSA maintainer at SUSE) - Standard quirk addition pattern used extensively throughout this file - Follows exact same format as dozens of other ASUS quirk entries ### 7. DEPENDENCY CHECK - The fixup `ALC287_FIXUP_CS35L41_I2C_2` has been in the kernel for some time, supporting multiple other ASUS models - No other commits are required for this to work - This should apply cleanly to stable trees that have the CS35L41 support infrastructure ### CONCLUSION This commit is a textbook example of what should be backported to stable trees: 1. **Falls under explicit exception**: Adding device IDs to existing drivers is explicitly allowed 2. **Minimal change**: Single line, single table entry 3. **Zero regression risk**: Cannot affect any hardware except the targeted laptop 4. **Uses existing infrastructure**: The fixup is already well-tested on similar ASUS models 5. **Fixes real user problem**: Enables audio on a production laptop 6. **Obviously correct**: Identical pattern to surrounding entries The risk-benefit analysis strongly favors backporting: virtually zero risk with clear user benefit (working audio on a specific laptop model). **YES** sound/hda/codecs/realtek/alc269.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index b45fcc9a3785e..008bf9d5148e1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6752,6 +6752,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A), SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1652, "ASUS ROG Zephyrus Do 15 SE", ALC289_FIXUP_ASUS_ZEPHYRUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1663, "ASUS GU603ZI/ZJ/ZQ/ZU/ZV", ALC285_FIXUP_ASUS_HEADSET_MIC), -- 2.51.0

11 hours, 16 minutes

1
8
0 0

[PATCH AUTOSEL 6.18-6.1] smb/client: fix NT_STATUS_NO_DATA_DETECTED value

by Sasha Levin

From: ChenXiaoSong <chenxiaosong(a)kylinos.cn> [ Upstream commit a1237c203f1757480dc2f3b930608ee00072d3cc ] This was reported by the KUnit tests in the later patches. See MS-ERREF 2.3.1 STATUS_NO_DATA_DETECTED. Keep it consistent with the value in the documentation. Signed-off-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Acked-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Analysis of Commit: smb/client: fix NT_STATUS_NO_DATA_DETECTED value ### 1. COMMIT MESSAGE ANALYSIS - Subject clearly states "fix" indicating a bug fix - References MS-ERREF 2.3.1 (Microsoft's official NTSTATUS documentation) as the authoritative source - Bug was discovered through KUnit tests - Has Acked-by from Paulo Alcantara (Red Hat SMB maintainer) and Signed- off-by from Steve French (primary SMB/CIFS maintainer) ### 2. CODE CHANGE ANALYSIS The change is a single-line fix in a header file: ```c -#define NT_STATUS_NO_DATA_DETECTED 0x8000001c +#define NT_STATUS_NO_DATA_DETECTED 0x80000022 ``` **Critical bug identified**: The OLD value `0x8000001c` was **duplicated** with another constant defined just a few lines above: ```c #define NT_STATUS_MEDIA_CHANGED 0x8000001c ``` This is clearly a bug - two distinct Windows NT error status codes were sharing the same numeric value. This would cause: - Incorrect error code interpretation when servers return STATUS_NO_DATA_DETECTED (0x80000022) - Potential confusion between STATUS_MEDIA_CHANGED and STATUS_NO_DATA_DETECTED The new value `0x80000022` matches the official Microsoft MS-ERREF specification for STATUS_NO_DATA_DETECTED. ### 3. CLASSIFICATION - **Bug fix**: Yes - corrects a provably incorrect constant value - **Feature addition**: No - **New API**: No - **Specification compliance fix**: Aligns with official Microsoft documentation ### 4. SCOPE AND RISK ASSESSMENT - **Size**: 1 line changed - **Files**: 1 header file - **Risk**: Extremely low - simply correcting a wrong numeric constant - **Subsystem**: SMB client (commonly used for network file sharing) This is about as low-risk as a fix can get - it's correcting a single constant value to match official documentation. The previous value was demonstrably wrong (duplicate of another constant). ### 5. USER IMPACT SMB is widely used for file sharing across networks. Having correct error status codes is important for proper error handling. While the practical impact depends on how this constant is used, having correct protocol constants is essential for interoperability. ### 6. STABILITY INDICATORS - Acked by Red Hat's SMB maintainer - Signed off by the primary CIFS/SMB maintainer (Steve French) - KUnit tests caught this issue, indicating testing coverage ### 7. DEPENDENCY CHECK - No dependencies on other commits - Standalone fix to a header constant - SMB client code exists in stable trees ### Summary **Meets stable criteria:** - ✅ Obviously correct (matches official MS-ERREF documentation) - ✅ Fixes a real bug (duplicate constant value) - ✅ Extremely small and contained (single line change) - ✅ No new features or APIs - ✅ Low risk (just correcting a constant value) **Risk vs Benefit:** - Risk: Minimal - changing a constant to its documented correct value - Benefit: Correct SMB error handling, protocol compliance This is a textbook example of a safe stable backport candidate: an obviously wrong value is corrected to match official documentation, the change is tiny, and there's no possibility of regression since the old value was demonstrably incorrect (it was a duplicate of NT_STATUS_MEDIA_CHANGED). **YES** fs/smb/client/nterr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/smb/client/nterr.h b/fs/smb/client/nterr.h index b3516c71cff77..09263c91d07a4 100644 --- a/fs/smb/client/nterr.h +++ b/fs/smb/client/nterr.h @@ -41,7 +41,7 @@ extern const struct nt_err_code_struct nt_errs[]; #define NT_STATUS_MEDIA_CHANGED 0x8000001c #define NT_STATUS_END_OF_MEDIA 0x8000001e #define NT_STATUS_MEDIA_CHECK 0x80000020 -#define NT_STATUS_NO_DATA_DETECTED 0x8000001c +#define NT_STATUS_NO_DATA_DETECTED 0x80000022 #define NT_STATUS_STOPPED_ON_SYMLINK 0x8000002d #define NT_STATUS_DEVICE_REQUIRES_CLEANING 0x80000288 #define NT_STATUS_DEVICE_DOOR_OPEN 0x80000289 -- 2.51.0

11 hours, 16 minutes

1
0
0 0

PROBLEM: hwclock busted w/ M48T59 RTC (regression)

by Nick Bowler

Hi, After a stable kernel update, the hwclock command seems no longer functional on my SPARC system with an ST M48T59Y-70PC1 RTC: # hwclock [...long delay...] hwclock: select() to /dev/rtc0 to wait for clock tick timed out On prior kernels, there is no problem: # hwclock 2025-10-22 22:21:04.806992-04:00 I reproduced the same failure on 6.18-rc2 and bisected to this commit: commit 795cda8338eab036013314dbc0b04aae728880ab Author: Esben Haabendal <esben(a)geanix.com> Date: Fri May 16 09:23:35 2025 +0200 rtc: interface: Fix long-standing race when setting alarm This commit was backported to all current 6.x stable branches, as well as 5.15.x, so they all have the same regression. Reverting this commit on top of 6.18-rc2 corrects the problem. Let me know if you need any more info! Thanks, Nick

13 hours, 53 minutes

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror