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

[PATCH 0/2] Two NVMe/FC bug fixes for -stable

by Ewan D. Milne

This patch series contains two fixes to the NVMe/FC transport code. The first one fixes a problem where we prematurely free the tagset based on an observation and a fix originally proposed by Ming Lei, with a further modification based on more extensive testing. The second one fixes a problem where we sometimes still had a workqueue item queued when we freed the nvme_fc_ctrl. Because both patches touch the same nvme_fc_delete_ctrl() function, they have to be applied in the correct order to merge cleanly. However they fix separate issues. Ewan D. Milne (2): nvme-fc: move tagset removal to nvme_fc_delete_ctrl() nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() drivers/nvme/host/fc.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) -- 2.43.0

1 day, 16 hours

3
5
0 0

Vendor Registration - Qatar Airways

by Qatar Airways

Dear Sir/Madam, We hope this message finds you well. Qatar Airways is pleased to announce the launch of its 2026/27 Expansion Program. We are currently seeking to engage with qualified Suppliers, Vendors, Manufacturers, and Contractors across a wide range of sectors. If your organization is interested in participating in this exciting initiative, we invite you to request our Vendor Application Form and submit your Expression of Interest (EOI) for evaluation. We look forward to the opportunity to collaborate and achieve mutual growth through this strategic partnership. Best regards, Hamza Mohammed Sahib Procurement & Logistics Manager Phone/ WhatsApp: +971-56-778-2809 Qatar Airways

1 day, 16 hours

1
0
0 0

[PATCH 05/15] dmaengine: idxd: fix device leaks on compat bind and unbind

by Johan Hovold

Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface. Fixes: 6e7f3ee97bbe ("dmaengine: idxd: move dsa_drv support to compatible mode") Cc: stable(a)vger.kernel.org # 5.15 Cc: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/idxd/compat.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/dma/idxd/compat.c b/drivers/dma/idxd/compat.c index eff9943f1a42..95b8ef958633 100644 --- a/drivers/dma/idxd/compat.c +++ b/drivers/dma/idxd/compat.c @@ -20,11 +20,16 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf, size_t c int rc = -ENODEV; dev = bus_find_device_by_name(bus, NULL, buf); - if (dev && dev->driver) { + if (!dev) + return -ENODEV; + + if (dev->driver) { device_driver_detach(dev); rc = count; } + put_device(dev); + return rc; } static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, 0200, NULL, unbind_store); @@ -38,9 +43,12 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t cou struct idxd_dev *idxd_dev; dev = bus_find_device_by_name(bus, NULL, buf); - if (!dev || dev->driver || drv != &dsa_drv.drv) + if (!dev) return -ENODEV; + if (dev->driver || drv != &dsa_drv.drv) + goto err_put_dev; + idxd_dev = confdev_to_idxd_dev(dev); if (is_idxd_dev(idxd_dev)) { alt_drv = driver_find("idxd", bus); @@ -53,13 +61,20 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t cou alt_drv = driver_find("user", bus); } if (!alt_drv) - return -ENODEV; + goto err_put_dev; rc = device_driver_attach(alt_drv, dev); if (rc < 0) - return rc; + goto err_put_dev; + + put_device(dev); return count; + +err_put_dev: + put_device(dev); + + return rc; } static DRIVER_ATTR_IGNORE_LOCKDEP(bind, 0200, NULL, bind_store); -- 2.51.0

1 day, 17 hours

2
2
0 0

[PATCH 15/15] dmaengine: ti: k3-udma: fix device leak on udma lookup

by Johan Hovold

Make sure to drop the reference taken when looking up the UDMA platform device. Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Fixes: 1438cde8fe9c ("dmaengine: ti: k3-udma: add missing put_device() call in of_xudma_dev_get()") Cc: stable(a)vger.kernel.org # 5.6: 1438cde8fe9c Cc: Grygorii Strashko <grygorii.strashko(a)ti.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/ti/k3-udma-private.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c index 05228bf00033..624360423ef1 100644 --- a/drivers/dma/ti/k3-udma-private.c +++ b/drivers/dma/ti/k3-udma-private.c @@ -42,9 +42,9 @@ struct udma_dev *of_xudma_dev_get(struct device_node *np, const char *property) } ud = platform_get_drvdata(pdev); + put_device(&pdev->dev); if (!ud) { pr_debug("UDMA has not been probed\n"); - put_device(&pdev->dev); return ERR_PTR(-EPROBE_DEFER); } -- 2.51.0

1 day, 17 hours

1
0
0 0

[PATCH 13/15] dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation

by Johan Hovold

Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation. Fixes: 42dbdcc6bf96 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx") Cc: stable(a)vger.kernel.org # 4.4 Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/ti/dma-crossbar.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/dma/ti/dma-crossbar.c b/drivers/dma/ti/dma-crossbar.c index e52b0e139900..ff05b150ad37 100644 --- a/drivers/dma/ti/dma-crossbar.c +++ b/drivers/dma/ti/dma-crossbar.c @@ -79,34 +79,35 @@ 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; + struct ti_am335x_xbar_map *map = ERR_PTR(-EINVAL); if (dma_spec->args_count != 3) - return ERR_PTR(-EINVAL); + goto out_put_pdev; 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); + goto out_put_pdev; } 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); + goto out_put_pdev; } /* 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); + goto out_put_pdev; } map = kzalloc(sizeof(*map), GFP_KERNEL); if (!map) { of_node_put(dma_spec->np); - return ERR_PTR(-ENOMEM); + map = ERR_PTR(-ENOMEM); + goto out_put_pdev; } map->dma_line = (u16)dma_spec->args[0]; @@ -120,6 +121,9 @@ 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); +out_put_pdev: + put_device(&pdev->dev); + return map; } -- 2.51.0

1 day, 17 hours

1
0
0 0

[PATCH 12/15] dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation

by Johan Hovold

Make sure to drop the reference taken when looking up the crossbar platform device during dra7x route allocation. Note that commit 615a4bfc426e ("dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate") fixed the leak in the error paths but the reference is still leaking on successful allocation. Fixes: a074ae38f859 ("dmaengine: Add driver for TI DMA crossbar on DRA7x") Fixes: 615a4bfc426e ("dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate") Cc: stable(a)vger.kernel.org # 4.2: 615a4bfc426e Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Cc: Miaoqian Lin <linmq006(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/ti/dma-crossbar.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/ti/dma-crossbar.c b/drivers/dma/ti/dma-crossbar.c index 7f17ee87a6dc..e52b0e139900 100644 --- a/drivers/dma/ti/dma-crossbar.c +++ b/drivers/dma/ti/dma-crossbar.c @@ -288,6 +288,8 @@ static void *ti_dra7_xbar_route_allocate(struct of_phandle_args *dma_spec, ti_dra7_xbar_write(xbar->iomem, map->xbar_out, map->xbar_in); + put_device(&pdev->dev); + return map; } -- 2.51.0

1 day, 17 hours

1
0
0 0

[PATCH 03/15] dmaengine: cv1800b-dmamux: fix device leak on route allocation

by Johan Hovold

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: db7d07b5add4 ("dmaengine: add driver for Sophgo CV18XX/SG200X dmamux") Cc: stable(a)vger.kernel.org # 6.17 Cc: Inochi Amaoto <inochiama(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/cv1800b-dmamux.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/dma/cv1800b-dmamux.c b/drivers/dma/cv1800b-dmamux.c index e900d6595617..f7a952fcbc7d 100644 --- a/drivers/dma/cv1800b-dmamux.c +++ b/drivers/dma/cv1800b-dmamux.c @@ -102,11 +102,11 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, struct llist_node *node; unsigned long flags; unsigned int chid, devid, cpuid; - int ret; + int ret = -EINVAL; if (dma_spec->args_count != DMAMUX_NCELLS) { dev_err(&pdev->dev, "invalid number of dma mux args\n"); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } devid = dma_spec->args[0]; @@ -115,18 +115,18 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, if (devid > MAX_DMA_MAPPING_ID) { dev_err(&pdev->dev, "invalid device id: %u\n", devid); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } if (cpuid > MAX_DMA_CPU_ID) { dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } 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); + goto err_put_pdev; } spin_lock_irqsave(&dmamux->lock, flags); @@ -136,8 +136,6 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, if (map->peripheral == devid && map->cpu == cpuid) goto found; } - - ret = -EINVAL; goto failed; } else { node = llist_del_first(&dmamux->free_maps); @@ -171,12 +169,17 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, dev_dbg(&pdev->dev, "register channel %u for req %u (cpu %u)\n", chid, devid, cpuid); + put_device(&pdev->dev); + return map; failed: spin_unlock_irqrestore(&dmamux->lock, flags); of_node_put(dma_spec->np); dev_err(&pdev->dev, "errno %d\n", ret); +err_put_pdev: + put_device(&pdev->dev); + return ERR_PTR(ret); } -- 2.51.0

1 day, 17 hours

1
0
0 0

[PATCH 02/15] dmaengine: bcm-sba-raid: fix device leak on probe

by Johan Hovold

Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind. Fixes: 743e1c8ffe4e ("dmaengine: Add Broadcom SBA RAID driver") Cc: stable(a)vger.kernel.org # 4.13 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/bcm-sba-raid.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c index 7f0e76439ce5..ed037fa883f6 100644 --- a/drivers/dma/bcm-sba-raid.c +++ b/drivers/dma/bcm-sba-raid.c @@ -1699,7 +1699,7 @@ static int sba_probe(struct platform_device *pdev) /* Prealloc channel resource */ ret = sba_prealloc_channel_resources(sba); if (ret) - goto fail_free_mchan; + goto fail_put_mbox; /* Check availability of debugfs */ if (!debugfs_initialized()) @@ -1729,6 +1729,8 @@ static int sba_probe(struct platform_device *pdev) fail_free_resources: debugfs_remove_recursive(sba->root); sba_freeup_channel_resources(sba); +fail_put_mbox: + put_device(sba->mbox_dev); fail_free_mchan: mbox_free_channel(sba->mchan); return ret; @@ -1744,6 +1746,8 @@ static void sba_remove(struct platform_device *pdev) sba_freeup_channel_resources(sba); + put_device(sba->mbox_dev); + mbox_free_channel(sba->mchan); } -- 2.51.0

1 day, 17 hours

1
0
0 0

[PATCH] dvb-usb: dtv5100: rewrite i2c message usb_control send/recv

by Nalivayko Sergey

syzbot reports a WARNING issue as below: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 5833 at drivers/usb/core/urb.c:413 usb_submit_urb+0x1112/0x1870 drivers/usb/core/urb.c:411 Modules linked in: CPU: 0 UID: 0 PID: 5833 Comm: syz-executor411 Not tainted 6.15.0-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> usb_start_wait_urb+0x114/0x4c0 drivers/usb/core/message.c:59 usb_internal_control_msg drivers/usb/core/message.c:103 [inline] usb_control_msg+0x232/0x3e0 drivers/usb/core/message.c:154 dtv5100_i2c_msg+0x250/0x330 drivers/media/usb/dvb-usb/dtv5100.c:60 dtv5100_i2c_xfer+0x1a4/0x3c0 drivers/media/usb/dvb-usb/dtv5100.c:86 __i2c_transfer+0x871/0x2170 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x25b/0x3a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x105/0x190 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x112/0x1b0 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev include/linux/uio.h:-1 [inline] vfs_writev+0x4a5/0x9a0 fs/read_write.c:1057 do_writev+0x14d/0x2d0 fs/read_write.c:1101 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The issue occurs due to insufficient validation of data passed to the USB API. In the current implementation, the case where the operation type is read but the read length is zero is not handled properly, which makes no sense. When usb_control_msg() is called with a PIPEOUT type and a read length of zero, a mismatch error occurs between the operation type and the expected transfer direction in function usb_submit_urb. This is the trigger for warning. Replace usb_control_msg() with usb_control_msg_recv() and usb_control_msg_send() to rely on the USB API for proper validation and prevent inconsistencies in the future. Reported-by: syzbot+0335df380edd9bd3ff70(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0335df380edd9bd3ff70 Fixes: 60688d5e6e6e ("V4L/DVB (8735): dtv5100: replace dummy frontend by zl10353") Cc: stable(a)vger.kernel.org Signed-off-by: Nalivayko Sergey <Sergey.Nalivayko(a)kaspersky.com> --- drivers/media/usb/dvb-usb/dtv5100.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dtv5100.c b/drivers/media/usb/dvb-usb/dtv5100.c index 3d85c6f7f6ec..05860f5d5053 100644 --- a/drivers/media/usb/dvb-usb/dtv5100.c +++ b/drivers/media/usb/dvb-usb/dtv5100.c @@ -26,40 +26,37 @@ static int dtv5100_i2c_msg(struct dvb_usb_device *d, u8 addr, u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen) { struct dtv5100_state *st = d->priv; - unsigned int pipe; u8 request; u8 type; u16 value; u16 index; + index = (addr << 8) + wbuf[0]; + + memcpy(st->data, rbuf, rlen); + msleep(1); /* avoid I2C errors */ + switch (wlen) { case 1: /* write { reg }, read { value } */ - pipe = usb_rcvctrlpipe(d->udev, 0); request = (addr == DTV5100_DEMOD_ADDR ? DTV5100_DEMOD_READ : DTV5100_TUNER_READ); type = USB_TYPE_VENDOR | USB_DIR_IN; value = 0; - break; + return usb_control_msg_recv(d->udev, 0, request, type, value, index, + st->data, rlen, DTV5100_USB_TIMEOUT, GFP_KERNEL); case 2: /* write { reg, value } */ - pipe = usb_sndctrlpipe(d->udev, 0); request = (addr == DTV5100_DEMOD_ADDR ? DTV5100_DEMOD_WRITE : DTV5100_TUNER_WRITE); type = USB_TYPE_VENDOR | USB_DIR_OUT; value = wbuf[1]; - break; + return usb_control_msg_send(d->udev, 0, request, type, value, index, + st->data, rlen, DTV5100_USB_TIMEOUT, GFP_KERNEL); default: warn("wlen = %x, aborting.", wlen); return -EINVAL; } - index = (addr << 8) + wbuf[0]; - - memcpy(st->data, rbuf, rlen); - msleep(1); /* avoid I2C errors */ - return usb_control_msg(d->udev, pipe, request, - type, value, index, st->data, rlen, - DTV5100_USB_TIMEOUT); } /* I2C */ -- 2.39.5

1 day, 17 hours

1
0
0 0

[PATCH] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

by Selvarasu Ganesan

This commit fixes the below warning that occurs when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous transfer on the same endpoint is still in progress. The gadget functions drivers can invoke usb_ep_enable (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from gadget driver. To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided. ------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Change-Id: Id292265a34448e566ef1ea882e313856423342dc Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f95d1369bbc6..23e5c111da7c 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -951,8 +951,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */ - if (usb_endpoint_xfer_bulk(desc) || - usb_endpoint_xfer_int(desc)) { + if ((usb_endpoint_xfer_bulk(desc) || + usb_endpoint_xfer_int(desc)) && + !(dep->flags & DWC3_EP_TRANSFER_STARTED)) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma; -- 2.34.1

1 day, 17 hours

1
1
0 0

[PATCH] drm/kmb: Fix error handling in kmb_probe

by Ma Ke

kmb_probe() obtain a reference to a platform device by of_find_device_by_node(). This call increases the reference count of the returned device, which should be dropped by calling put_device() when the device is no longer needed. However, the code fails to call put_device() in several error handling paths and the normal device removal path. This could result in reference count leaks that prevent the proper cleanup of the platform device when the driver is unloaded or during error recovery. Add put_device() in all code paths where dsi_pdev is no longer needed, including error paths and the normal removal path. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/kmb/kmb_drv.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c index 32cda134ae3e..4fc9fdf92118 100644 --- a/drivers/gpu/drm/kmb/kmb_drv.c +++ b/drivers/gpu/drm/kmb/kmb_drv.c @@ -473,6 +473,8 @@ static void kmb_remove(struct platform_device *pdev) /* Unregister DSI host */ kmb_dsi_host_unregister(kmb->kmb_dsi); + if (kmb->kmb_dsi && kmb->kmb_dsi->pdev) + put_device(&kmb->kmb_dsi->pdev->dev); drm_atomic_helper_shutdown(drm); } @@ -517,17 +519,20 @@ static int kmb_probe(struct platform_device *pdev) ret = kmb_dsi_host_bridge_init(get_device(&dsi_pdev->dev)); if (ret == -EPROBE_DEFER) { - return -EPROBE_DEFER; + ret = -EPROBE_DEFER; + goto err_free2; } else if (ret) { DRM_ERROR("probe failed to initialize DSI host bridge\n"); - return ret; + goto err_free2; } /* Create DRM device */ kmb = devm_drm_dev_alloc(dev, &kmb_driver, struct kmb_drm_private, drm); - if (IS_ERR(kmb)) - return PTR_ERR(kmb); + if (IS_ERR(kmb)) { + ret = PTR_ERR(kmb); + goto err_free2; + } dev_set_drvdata(dev, &kmb->drm); @@ -576,7 +581,8 @@ static int kmb_probe(struct platform_device *pdev) err_free1: dev_set_drvdata(dev, NULL); kmb_dsi_host_unregister(kmb->kmb_dsi); - + err_free2: + put_device(&dsi_pdev->dev); return ret; } -- 2.17.1

1 day, 18 hours

2
1
0 0

[PATCH 5.4.y] mm/ksm: fix flag-dropping behavior in ksm_madvise

by Jakub Acs

[ Upstream commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 ] syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 <snip other registers, drop unreliable trace> [ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm(a)linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: SeongJae Park <sj(a)kernel.org> Tested-by: Alice Ryhl <aliceryhl(a)google.com> Tested-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Cc: Xu Xin <xu.xin16(a)zte.com.cn> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [ acsjakub: drop rust-compatibility change (no rust in 5.4) ] Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> --- Why sending to stable version from before "fixes"? In the original patch, I set fixes tag to the change that allows the panic to manifest, not to the one that is real root-cause of the problem. The change that introduced the root-cause of the problem is: f8af4da3b4c1 ("ksm: the mm interface to ksm"), as pointed out by Vlastimil in [1]. Hence, as the older kernels can be affected by the flag-drop as well, backport to older kernels. [1]: https://lore.kernel.org/all/13c7242e-3a40-469b-9e99-8a65a21449bb@suse.cz/ include/linux/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 57cba6e4fdcd..be8c793233d3 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -293,7 +293,7 @@ extern unsigned int kobjsize(const void *objp); #define VM_MIXEDMAP 0x10000000 /* Can contain "struct page" and pure PFN pages */ #define VM_HUGEPAGE 0x20000000 /* MADV_HUGEPAGE marked this vma */ #define VM_NOHUGEPAGE 0x40000000 /* MADV_NOHUGEPAGE marked this vma */ -#define VM_MERGEABLE 0x80000000 /* KSM may merge identical pages */ +#define VM_MERGEABLE BIT(31) /* KSM may merge identical pages */ #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS #define VM_HIGH_ARCH_BIT_0 32 /* bit only usable on 64-bit architectures */ -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

1 day, 18 hours

2
1
0 0

[PATCH 5.10] lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN

by Eric Biggers

commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream. On big endian arm kernels, the arm optimized Curve25519 code produces incorrect outputs and fails the Curve25519 test. This has been true ever since this code was added. It seems that hardly anyone (or even no one?) actually uses big endian arm kernels. But as long as they're ostensibly supported, we should disable this code on them so that it's not accidentally used. Note: for future-proofing, use !CPU_BIG_ENDIAN instead of CPU_LITTLE_ENDIAN. Both of these are arch-specific options that could get removed in the future if big endian support gets dropped. Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Cc: stable(a)vger.kernel.org Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Link: https://lore.kernel.org/r/20251104054906.716914-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- arch/arm/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig index c46c05548080..c5d676e7f16b 100644 --- a/arch/arm/crypto/Kconfig +++ b/arch/arm/crypto/Kconfig @@ -145,10 +145,10 @@ config CRYPTO_NHPOLY1305_NEON depends on KERNEL_MODE_NEON select CRYPTO_NHPOLY1305 config CRYPTO_CURVE25519_NEON tristate "NEON accelerated Curve25519 scalar multiplication library" - depends on KERNEL_MODE_NEON + depends on KERNEL_MODE_NEON && !CPU_BIG_ENDIAN select CRYPTO_LIB_CURVE25519_GENERIC select CRYPTO_ARCH_HAVE_LIB_CURVE25519 endif base-commit: df70e44fa05b01476a78d0f6a210354784ff0992 -- 2.51.2

1 day, 18 hours

2
1
0 0

[PATCH] 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

1 day, 18 hours

2
1
0 0

[PATCH 5.10.y] mm/ksm: fix flag-dropping behavior in ksm_madvise

by Jakub Acs

[ Upstream commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 ] syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 <snip other registers, drop unreliable trace> [ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm(a)linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: SeongJae Park <sj(a)kernel.org> Tested-by: Alice Ryhl <aliceryhl(a)google.com> Tested-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Cc: Xu Xin <xu.xin16(a)zte.com.cn> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [ acsjakub: drop rust-compatibility change (no rust in 5.10) ] Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> --- Why sending to stable version from before "fixes"? In the original patch, I set fixes tag to the change that allows the panic to manifest, not to the one that is real root-cause of the problem. The change that introduced the root-cause of the problem is: f8af4da3b4c1 ("ksm: the mm interface to ksm"), as pointed out by Vlastimil in [1]. Hence, as the older kernels can be affected by the flag-drop as well, backport to older kernels. [1]: https://lore.kernel.org/all/13c7242e-3a40-469b-9e99-8a65a21449bb@suse.cz/ include/linux/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index e168d87d6f2e..4787d39bbad4 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -296,7 +296,7 @@ extern unsigned int kobjsize(const void *objp); #define VM_MIXEDMAP 0x10000000 /* Can contain "struct page" and pure PFN pages */ #define VM_HUGEPAGE 0x20000000 /* MADV_HUGEPAGE marked this vma */ #define VM_NOHUGEPAGE 0x40000000 /* MADV_NOHUGEPAGE marked this vma */ -#define VM_MERGEABLE 0x80000000 /* KSM may merge identical pages */ +#define VM_MERGEABLE BIT(31) /* KSM may merge identical pages */ #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS #define VM_HIGH_ARCH_BIT_0 32 /* bit only usable on 64-bit architectures */ -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

1 day, 18 hours

2
1
0 0

[PATCH v2 5.10.y] fsdax: mark the iomap argument to dax_iomap_sector as const

by Eliav Farber

From: Christoph Hellwig <hch(a)lst.de> [ Upstream commit 7e4f4b2d689d959b03cb07dfbdb97b9696cb1076 ] Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Eliav Farber <farbere(a)amazon.com> --- V1 -> V2: Added missing 'Signed-off-by' Fixes: fs/dax.c: In function 'dax_iomap_iter': fs/dax.c:1147:44: error: passing argument 1 of 'dax_iomap_sector' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] const sector_t sector = dax_iomap_sector(iomap, pos); ^~~~~ fs/dax.c:1009:17: note: expected 'struct iomap *' but argument is of type 'const struct iomap *' static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos) ^~~~~~~~~~~~~~~~ The issue was introduced by the cherry-pick of commit 8df4919cb921 ("fsdax: switch dax_iomap_rw to use iomap_iter") https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/… The upstream change made callers pass a const struct iomap *: const struct iomap *iomap = &iomi->iomap; but dax_iomap_sector() still expected a mutable pointer: static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos) fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dax.c b/fs/dax.c index 91820b9b50b7..2ca33ef5d519 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -1006,7 +1006,7 @@ int dax_writeback_mapping_range(struct address_space *mapping, } EXPORT_SYMBOL_GPL(dax_writeback_mapping_range); -static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos) +static sector_t dax_iomap_sector(const struct iomap *iomap, loff_t pos) { return (iomap->addr + (pos & PAGE_MASK) - iomap->offset) >> 9; } -- 2.47.3

1 day, 18 hours

2
1
0 0

[PATCH 5.15] lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN

by Eric Biggers

commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream. On big endian arm kernels, the arm optimized Curve25519 code produces incorrect outputs and fails the Curve25519 test. This has been true ever since this code was added. It seems that hardly anyone (or even no one?) actually uses big endian arm kernels. But as long as they're ostensibly supported, we should disable this code on them so that it's not accidentally used. Note: for future-proofing, use !CPU_BIG_ENDIAN instead of CPU_LITTLE_ENDIAN. Both of these are arch-specific options that could get removed in the future if big endian support gets dropped. Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Cc: stable(a)vger.kernel.org Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Link: https://lore.kernel.org/r/20251104054906.716914-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- arch/arm/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig index 149a5bd6b88c..d3d318df0e38 100644 --- a/arch/arm/crypto/Kconfig +++ b/arch/arm/crypto/Kconfig @@ -164,10 +164,10 @@ config CRYPTO_NHPOLY1305_NEON depends on KERNEL_MODE_NEON select CRYPTO_NHPOLY1305 config CRYPTO_CURVE25519_NEON tristate "NEON accelerated Curve25519 scalar multiplication library" - depends on KERNEL_MODE_NEON + depends on KERNEL_MODE_NEON && !CPU_BIG_ENDIAN select CRYPTO_LIB_CURVE25519_GENERIC select CRYPTO_ARCH_HAVE_LIB_CURVE25519 endif base-commit: cc5ec87693063acebb60f587e8a019ba9b94ae0e -- 2.51.2

1 day, 18 hours

2
1
0 0

[PATCH 5.15.y] mm/ksm: fix flag-dropping behavior in ksm_madvise

by Jakub Acs

[ Upstream commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 ] syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 <snip other registers, drop unreliable trace> [ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm(a)linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: SeongJae Park <sj(a)kernel.org> Tested-by: Alice Ryhl <aliceryhl(a)google.com> Tested-by: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Cc: Xu Xin <xu.xin16(a)zte.com.cn> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [ acsjakub: drop rust-compatibility change (no rust in 5.15) ] Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> --- Why sending to stable version from before "fixes"? In the original patch, I set fixes tag to the change that allows the panic to manifest, not to the one that is real root-cause of the problem. The change that introduced the root-cause of the problem is: f8af4da3b4c1 ("ksm: the mm interface to ksm"), as pointed out by Vlastimil in [1]. Hence, as the older kernels can be affected by the flag-drop as well, backport to older kernels. [1]: https://lore.kernel.org/all/13c7242e-3a40-469b-9e99-8a65a21449bb@suse.cz/ include/linux/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 3598925561b1..071dd864a7b2 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -310,7 +310,7 @@ extern unsigned int kobjsize(const void *objp); #define VM_MIXEDMAP 0x10000000 /* Can contain "struct page" and pure PFN pages */ #define VM_HUGEPAGE 0x20000000 /* MADV_HUGEPAGE marked this vma */ #define VM_NOHUGEPAGE 0x40000000 /* MADV_NOHUGEPAGE marked this vma */ -#define VM_MERGEABLE 0x80000000 /* KSM may merge identical pages */ +#define VM_MERGEABLE BIT(31) /* KSM may merge identical pages */ #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS #define VM_HIGH_ARCH_BIT_0 32 /* bit only usable on 64-bit architectures */ -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

1 day, 18 hours

2
1
0 0

FAILED: patch "[PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR" 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 e84cb860ac3ce67ec6ecc364433fd5b412c448bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102646-unwary-premises-4a2c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:26 +0200 Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index e0f44dc232aa..2ae95476dba3 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) } subflow: + /* No need to try establishing subflows to remote id0 if not allowed */ + if (mptcp_pm_add_addr_c_flag_case(msk)) + goto exit; + /* check if should create a new subflow */ while (msk->pm.local_addr_used < endp_subflow_max && msk->pm.extra_subflows < limit_extra_subflows) { @@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) __mptcp_subflow_connect(sk, &local, &addrs[i]); spin_lock_bh(&msk->pm.lock); } + +exit: mptcp_pm_nl_check_work_pending(msk); }

1 day, 19 hours

3
2
0 0

[PATCH v2 0/9] dt-bindings: PCI: qcom: Add missing required power-domains and resets

by Krzysztof Kozlowski

Changes in v2: - Add also resets - Drop cc-stable tag in the last patch - Link to v1: https://patch.msgid.link/20251029-dt-bindings-pci-qcom-fixes-power-domains-… Recent binding changes forgot to make power-domains and resets required. I am not updating SC8180xp because it will be fixed other way in my next patchset. Best regards, Krzysztof --- Krzysztof Kozlowski (9): dt-bindings: PCI: qcom,pcie-sa8775p: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sc7280: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sc8280xp: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8150: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8250: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8350: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8450: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8550: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-x1e80100: Add missing required power-domains and resets Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml | 3 +++ Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml | 3 +++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml | 5 +++++ 9 files changed, 41 insertions(+) --- base-commit: 326bbf6e2b1ce8d1e6166cce2ca414aa241c382f change-id: 20251029-dt-bindings-pci-qcom-fixes-power-domains-36a669b2e252 Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

1 day, 20 hours

4
10
0 0

[PATCH] media: az6007: validate I2C message length

by Nalivayko Sergey

syzbot reports a UBSAN issue as below: UBSAN: array-index-out-of-bounds in drivers/media/usb/dvb-usb-v2/az6007.c:821:30 index 4096 is out of range for type 'unsigned char [4096]' CPU: 1 UID: 0 PID: 5832 Comm: syz-executor328 Not tainted 6.15.0-rc2-syzkaller-00493-gac71fabf1567 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x11c/0x160 lib/ubsan.c:453 az6007_i2c_xfer+0x549/0xc30 drivers/media/usb/dvb-usb-v2/az6007.c:821 __i2c_transfer+0x6b3/0x2190 drivers/i2c/i2c-core-base.c:2259 i2c_transfer drivers/i2c/i2c-core-base.c:2315 [inline] i2c_transfer+0x1da/0x380 drivers/i2c/i2c-core-base.c:2291 i2c_transfer_buffer_flags+0x10c/0x190 drivers/i2c/i2c-core-base.c:2343 i2c_master_recv include/linux/i2c.h:79 [inline] i2cdev_read+0x111/0x280 drivers/i2c/i2c-dev.c:155 do_loop_readv_writev fs/read_write.c:845 [inline] do_loop_readv_writev fs/read_write.c:833 [inline] vfs_readv+0x6bc/0x8a0 fs/read_write.c:1018 do_preadv+0x1af/0x270 fs/read_write.c:1130 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The issue occurs because the az6007 driver does not validate the length of the received I2C message. While iterating over st->data, the index 'j' may exceed the maximum buffer size of 4096 elements. Add validation of msgs.len based on buffer length value passed to __az6007_read/write functions to prevent out-of-bounds access. Reported-by: syzbot+0192952caa411a3be209(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d8913f1760bc090ee46e\ Fixes: 71d676345698 ("[media] dvb: Add a new driver for az6007") Cc: stable(a)vger.kernel.org Signed-off-by: Nalivayko Sergey <Sergey.Nalivayko(a)kaspersky.com> --- drivers/media/usb/dvb-usb-v2/az6007.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/dvb-usb-v2/az6007.c b/drivers/media/usb/dvb-usb-v2/az6007.c index 65ef045b74ca..c966de4ea6e1 100644 --- a/drivers/media/usb/dvb-usb-v2/az6007.c +++ b/drivers/media/usb/dvb-usb-v2/az6007.c @@ -770,6 +770,10 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], if (az6007_xfer_debug) printk(KERN_DEBUG "az6007: I2C W/R addr=0x%x len=%d/%d\n", addr, msgs[i].len, msgs[i + 1].len); + if (msgs[i + 1].len + 6 > ARRAY_SIZE(st->data)) { + ret = -EIO; + goto err; + } req = AZ6007_I2C_RD; index = msgs[i].buf[0]; value = addr | (1 << 8); @@ -788,7 +792,7 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], if (az6007_xfer_debug) printk(KERN_DEBUG "az6007: I2C W addr=0x%x len=%d\n", addr, msgs[i].len); - if (msgs[i].len < 1) { + if (msgs[i].len < 1 || msgs[i].len - 1 > ARRAY_SIZE(st->data)) { ret = -EIO; goto err; } @@ -806,7 +810,7 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], if (az6007_xfer_debug) printk(KERN_DEBUG "az6007: I2C R addr=0x%x len=%d\n", addr, msgs[i].len); - if (msgs[i].len < 1) { + if (msgs[i].len < 1 || msgs[i].len + 6 > ARRAY_SIZE(st->data)) { ret = -EIO; goto err; } -- 2.39.5

1 day, 20 hours

1
0
0 0

[PATCH 5.10] ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()

by Alexandra Diupina

From: Takashi Iwai <tiwai(a)suse.de> commit 94c1ceb043c1a002de9649bb630c8e8347645982 upstream. snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue. Fixes: 29c8e4398f02 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://lore.kernel.org/r/20220801165420.25978-4-tiwai@suse.de Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Alexandra Diupina <adiupina(a)astralinux.ru> --- Backport fix for CVE-2022-50050 sound/soc/sof/intel/hda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index b4cc72483137..1d879c2b81e1 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -437,7 +437,7 @@ static void hda_dsp_dump_ext_rom_status(struct snd_sof_dev *sdev) for (i = 0; i < HDA_EXT_ROM_STATUS_SIZE; i++) { value = snd_sof_dsp_read(sdev, HDA_DSP_BAR, HDA_DSP_SRAM_REG_ROM_STATUS + i * 0x4); - len += snprintf(msg + len, sizeof(msg) - len, " 0x%x", value); + len += scnprintf(msg + len, sizeof(msg) - len, " 0x%x", value); } sof_dev_dbg_or_err(sdev->dev, hda->boot_iteration == HDA_FW_BOOT_ATTEMPTS, -- 2.30.2

1 day, 21 hours

1
0
0 0

[PATCH] RDMA/irdma: fix Kconfig dependency

by Wentao Guan

Any combination of (IDPF || ICE || I40E) can register auxiliary_dev, so use '||' instead of '&&' in IRDMA config. Cc: stable(a)vger.kernel.org Fixes: 060842fed53f ("RDMA/irdma: Update Kconfig") Fixes: fa0cf568fd76 ("RDMA/irdma: Add irdma Kconfig/Makefile and remove i40iw") Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> --- PS: found in stable v6.12.58, it makes IRDMA be removed when select ICE+I40E+(!IDPF). --- --- drivers/infiniband/hw/irdma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/irdma/Kconfig b/drivers/infiniband/hw/irdma/Kconfig index 0bd7e3fca1fbb..83a55b23c1325 100644 --- a/drivers/infiniband/hw/irdma/Kconfig +++ b/drivers/infiniband/hw/irdma/Kconfig @@ -4,7 +4,7 @@ config INFINIBAND_IRDMA depends on INET depends on IPV6 || !IPV6 depends on PCI - depends on IDPF && ICE && I40E + depends on IDPF || ICE || I40E select GENERIC_ALLOCATOR select AUXILIARY_BUS select CRC32 base-commit: 9b9e43704d2b05514aeeaea36311addba2c72408 -- 2.20.1

1 day, 21 hours

1
0
0 0

[PATCH] PCI: j721e: Add config guards for Cadence Host and Endpoint library APIs

by Siddharth Vadapalli

Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail… Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- drivers/pci/controller/cadence/pci-j721e.c | 43 +++++++++++++--------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c index 5bc5ab20aa6d..67c5e02afccf 100644 --- a/drivers/pci/controller/cadence/pci-j721e.c +++ b/drivers/pci/controller/cadence/pci-j721e.c @@ -628,10 +628,12 @@ static int j721e_pcie_probe(struct platform_device *pdev) gpiod_set_value_cansleep(gpiod, 1); } - ret = cdns_pcie_host_setup(rc); - if (ret < 0) { - clk_disable_unprepare(pcie->refclk); - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_setup(rc); + if (ret < 0) { + clk_disable_unprepare(pcie->refclk); + goto err_pcie_setup; + } } break; @@ -642,9 +644,11 @@ static int j721e_pcie_probe(struct platform_device *pdev) goto err_get_sync; } - ret = cdns_pcie_ep_setup(ep); - if (ret < 0) - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { + ret = cdns_pcie_ep_setup(ep); + if (ret < 0) + goto err_pcie_setup; + } break; } @@ -669,10 +673,11 @@ static void j721e_pcie_remove(struct platform_device *pdev) struct cdns_pcie_ep *ep; struct cdns_pcie_rc *rc; - if (pcie->mode == PCI_MODE_RC) { + if (IS_ENABLED(CONFIG_PCI_J721E_HOST) && + pcie->mode == PCI_MODE_RC) { rc = container_of(cdns_pcie, struct cdns_pcie_rc, pcie); cdns_pcie_host_disable(rc); - } else { + } else if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { ep = container_of(cdns_pcie, struct cdns_pcie_ep, pcie); cdns_pcie_ep_disable(ep); } @@ -739,10 +744,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) gpiod_set_value_cansleep(pcie->reset_gpio, 1); } - ret = cdns_pcie_host_link_setup(rc); - if (ret < 0) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_link_setup(rc); + if (ret < 0) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } /* @@ -752,10 +759,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) for (enum cdns_pcie_rp_bar bar = RP_BAR0; bar <= RP_NO_BAR; bar++) rc->avail_ib_bar[bar] = true; - ret = cdns_pcie_host_init(rc); - if (ret) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_init(rc); + if (ret) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } } -- 2.51.1

1 day, 21 hours

2
1
0 0

[REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

by incogcyberpunk＠proton.me

#regzbot introduced: v6.13.1..v6.13.2 Distro: Arch Linux Kernel: since v6.13.2 The bluetooth adapter would be recognized and the bluetooth worked flawlessly till v6.13.1 , but since the v6.13.2 , the bluetooth adapter doesn't get recognized by the bluetooth service and therefore the bluetooth functionality doesn't work . I suspect the bluetooth's driver failing to load at the kernel-level. - The output of bluetoothctl : $: bluetoothctl Agent registered [bluetoothctl]> list [bluetoothctl]> devices No default controller available [bluetoothctl]> - The output of systemctl status bluetooth.service : ● bluetooth.service - Bluetooth service Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: disabled) Active: active (running) since Sat 2025-11-15 22:57:00 +0545; 1 day 8h ago Invocation: bddf190655fd4a4290d41cde594f2efa Docs: man:bluetoothd(8) Main PID: 617 (bluetoothd) Status: "Running" Tasks: 1 (limit: 18701) Memory: 2.8M (peak: 3.8M) CPU: 38ms CGroup: /system.slice/bluetooth.service └─617 /usr/lib/bluetooth/bluetoothd Nov 15 22:57:00 Incog systemd[1]: Starting Bluetooth service... Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth daemon 5.84 Nov 15 22:57:00 Incog systemd[1]: Started Bluetooth service. Nov 15 22:57:00 Incog bluetoothd[617]: Starting SDP server Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth management interface 1.23 initialized - The output of lspci is attached below . - The logs for journalctl -b for both v6.13.1 and v6.13.2 are attached below. Regards, IncogCyberpunk

1 day, 22 hours

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror