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

[PATCH 4/4] xhci: dbc: Flush queued requests before stopping dbc

by Mathias Nyman

Flush dbc requests when dbc is stopped and transfer rings are freed. Failure to flush them lead to leaking memory and dbc completing odd requests after resuming from suspend, leading to error messages such as: [ 95.344392] xhci_hcd 0000:00:0d.0: no matched request Cc: stable(a)vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-dbgcap.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 0d4ce5734165..06a2edb9e86e 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -652,6 +652,10 @@ static void xhci_dbc_stop(struct xhci_dbc *dbc) case DS_DISABLED: return; case DS_CONFIGURED: + spin_lock(&dbc->lock); + xhci_dbc_flush_requests(dbc); + spin_unlock(&dbc->lock); + if (dbc->driver->disconnect) dbc->driver->disconnect(dbc); break; -- 2.43.0

4 days, 13 hours

1
0
0 0

[PATCH 3/4] xhci: dbctty: disable ECHO flag by default

by Mathias Nyman

From: Łukasz Bartosik <ukaszb(a)chromium.org> When /dev/ttyDBC0 device is created then by default ECHO flag is set for the terminal device. However if data arrives from a peer before application using /dev/ttyDBC0 applies its set of terminal flags then the arriving data will be echoed which might not be desired behavior. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable(a)vger.kernel.org Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-dbgtty.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index 60ed753c85bb..d894081d8d15 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -617,6 +617,7 @@ int dbc_tty_init(void) dbc_tty_driver->type = TTY_DRIVER_TYPE_SERIAL; dbc_tty_driver->subtype = SERIAL_TYPE_NORMAL; dbc_tty_driver->init_termios = tty_std_termios; + dbc_tty_driver->init_termios.c_lflag &= ~ECHO; dbc_tty_driver->init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL; dbc_tty_driver->init_termios.c_ispeed = 9600; -- 2.43.0

4 days, 13 hours

1
0
0 0

[PATCH 2/4] xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMS

by Mathias Nyman

From: Hongyu Xie <xiehongyu1(a)kylinos.cn> Disable stream for platform xHC controller with broken stream. Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable") Cc: stable(a)vger.kernel.org # 5.4 Signed-off-by: Hongyu Xie <xiehongyu1(a)kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-plat.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 6dab142e7278..c79d5ed48a08 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -328,7 +328,8 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s } usb3_hcd = xhci_get_usb3_hcd(xhci); - if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4) + if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4 && + !(xhci->quirks & XHCI_BROKEN_STREAMS)) usb3_hcd->can_do_streams = 1; if (xhci->shared_hcd) { -- 2.43.0

4 days, 13 hours

1
0
0 0

[PATCH 1/4] usb: xhci: quirk for data loss in ISOC transfers

by Mathias Nyman

From: Raju Rangoju <Raju.Rangoju(a)amd.com> During the High-Speed Isochronous Audio transfers, xHCI controller on certain AMD platforms experiences momentary data loss. This results in Missed Service Errors (MSE) being generated by the xHCI. The root cause of the MSE is attributed to the ISOC OUT endpoint being omitted from scheduling. This can happen when an IN endpoint with a 64ms service interval either is pre-scheduled prior to the ISOC OUT endpoint or the interval of the ISOC OUT endpoint is shorter than that of the IN endpoint. Consequently, the OUT service is neglected when an IN endpoint with a service interval exceeding 32ms is scheduled concurrently (every 64ms in this scenario). This issue is particularly seen on certain older AMD platforms. To mitigate this problem, it is recommended to adjust the service interval of the IN endpoint to not exceed 32ms (interval 8). This adjustment ensures that the OUT endpoint will not be bypassed, even if a smaller interval value is utilized. Cc: stable(a)vger.kernel.org Signed-off-by: Raju Rangoju <Raju.Rangoju(a)amd.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-mem.c | 4 ++++ drivers/usb/host/xhci-pci.c | 25 +++++++++++++++++++++++++ drivers/usb/host/xhci.h | 1 + 3 files changed, 30 insertions(+) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index bd745a0f2f78..6680afa4f596 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1449,6 +1449,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, /* Periodic endpoint bInterval limit quirk */ if (usb_endpoint_xfer_int(&ep->desc) || usb_endpoint_xfer_isoc(&ep->desc)) { + if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) && + interval >= 9) { + interval = 8; + } if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) && udev->speed >= USB_SPEED_HIGH && interval >= 7) { diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 0c481cbc8f08..00fac8b233d2 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -71,12 +71,22 @@ #define PCI_DEVICE_ID_INTEL_TITAN_RIDGE_4C_XHCI 0x15ec #define PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_XHCI 0x15f0 +#define PCI_DEVICE_ID_AMD_ARIEL_TYPEC_XHCI 0x13ed +#define PCI_DEVICE_ID_AMD_ARIEL_TYPEA_XHCI 0x13ee +#define PCI_DEVICE_ID_AMD_STARSHIP_XHCI 0x148c +#define PCI_DEVICE_ID_AMD_FIREFLIGHT_15D4_XHCI 0x15d4 +#define PCI_DEVICE_ID_AMD_FIREFLIGHT_15D5_XHCI 0x15d5 +#define PCI_DEVICE_ID_AMD_RAVEN_15E0_XHCI 0x15e0 +#define PCI_DEVICE_ID_AMD_RAVEN_15E1_XHCI 0x15e1 +#define PCI_DEVICE_ID_AMD_RAVEN2_XHCI 0x15e5 #define PCI_DEVICE_ID_AMD_RENOIR_XHCI 0x1639 #define PCI_DEVICE_ID_AMD_PROMONTORYA_4 0x43b9 #define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba #define PCI_DEVICE_ID_AMD_PROMONTORYA_2 0x43bb #define PCI_DEVICE_ID_AMD_PROMONTORYA_1 0x43bc +#define PCI_DEVICE_ID_ATI_NAVI10_7316_XHCI 0x7316 + #define PCI_DEVICE_ID_ASMEDIA_1042_XHCI 0x1042 #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142 #define PCI_DEVICE_ID_ASMEDIA_1142_XHCI 0x1242 @@ -280,6 +290,21 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) if (pdev->vendor == PCI_VENDOR_ID_NEC) xhci->quirks |= XHCI_NEC_HOST; + if (pdev->vendor == PCI_VENDOR_ID_AMD && + (pdev->device == PCI_DEVICE_ID_AMD_ARIEL_TYPEC_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_ARIEL_TYPEA_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_STARSHIP_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_FIREFLIGHT_15D4_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_FIREFLIGHT_15D5_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_RAVEN_15E0_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_RAVEN_15E1_XHCI || + pdev->device == PCI_DEVICE_ID_AMD_RAVEN2_XHCI)) + xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_9; + + if (pdev->vendor == PCI_VENDOR_ID_ATI && + pdev->device == PCI_DEVICE_ID_ATI_NAVI10_7316_XHCI) + xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_9; + if (pdev->vendor == PCI_VENDOR_ID_AMD && xhci->hci_version == 0x96) xhci->quirks |= XHCI_AMD_0x96_HOST; diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index fa1ea0e0c7fb..a20f4e7cd43a 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1643,6 +1643,7 @@ struct xhci_hcd { #define XHCI_WRITE_64_HI_LO BIT_ULL(47) #define XHCI_CDNS_SCTX_QUIRK BIT_ULL(48) #define XHCI_ETRON_HOST BIT_ULL(49) +#define XHCI_LIMIT_ENDPOINT_INTERVAL_9 BIT_ULL(50) unsigned int num_active_eps; unsigned int limit_active_eps; -- 2.43.0

4 days, 13 hours

1
0
0 0

Re: [PATCH v5] virtio_blk: Fix disk deletion hang on device surprise removal

by Stefan Hajnoczi

On Mon, Jun 02, 2025 at 02:44:33AM +0000, Parav Pandit wrote: > When the PCI device is surprise removed, requests may not complete > the device as the VQ is marked as broken. Due to this, the disk > deletion hangs. There are loops in the core virtio driver code that expect device register reads to eventually return 0: drivers/virtio/virtio_pci_modern.c:vp_reset() drivers/virtio/virtio_pci_modern_dev.c:vp_modern_set_queue_reset() Is there a hang if these loops are hit when a device has been surprise removed? I'm trying to understand whether surprise removal is fully supported or whether this patch is one step in that direction. Apart from that, I'm happy with the virtio_blk.c aspects of the patch: Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com> > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however > when the driver knows about unresponsive block device, swiftly clearing > them enables users and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in > virtio used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device") > Cc: stable(a)vger.kernel.org > Reported-by: Li RongQing <lirongqing(a)baidu.com> > Closes: https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9b4741@bai… > Reviewed-by: Max Gurtovoy <mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin <israelr(a)nvidia.com> > Signed-off-by: Parav Pandit <parav(a)nvidia.com> > > --- > v4->v5: > - fixed comment style where comment to start with one empty line at start > - Addressed comments from Alok > - fixed typo in broken vq check > v3->v4: > - Addressed comments from Michael > - renamed virtblk_request_cancel() to > virtblk_complete_request_with_ioerr() > - Added comments for virtblk_complete_request_with_ioerr() > - Renamed virtblk_broken_device_cleanup() to > virtblk_cleanup_broken_device() > - Added comments for virtblk_cleanup_broken_device() > - Moved the broken vq check in virtblk_remove() > - Fixed comment style to have first empty line > - replaced freezed to frozen > - Fixed comments rephrased > > v2->v3: > - Addressed comments from Michael > - updated comment for synchronizing with callbacks > > v1->v2: > - Addressed comments from Stephan > - fixed spelling to 'waiting' > - Addressed comments from Michael > - Dropped checking broken vq from queue_rq() and queue_rqs() > because it is checked in lower layer routines in virtio core > > v0->v1: > - Fixed comments from Stefan to rename a cleanup function > - Improved logic for handling any outstanding requests > in bio layer > - improved cancel callback to sync with ongoing done() > --- > drivers/block/virtio_blk.c | 95 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 95 insertions(+) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index 7cffea01d868..c5e383c0ac48 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -1554,6 +1554,98 @@ static int virtblk_probe(struct virtio_device *vdev) > return err; > } > > +/* > + * If the vq is broken, device will not complete requests. > + * So we do it for the device. > + */ > +static bool virtblk_complete_request_with_ioerr(struct request *rq, void *data) > +{ > + struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq); > + struct virtio_blk *vblk = data; > + struct virtio_blk_vq *vq; > + unsigned long flags; > + > + vq = &vblk->vqs[rq->mq_hctx->queue_num]; > + > + spin_lock_irqsave(&vq->lock, flags); > + > + vbr->in_hdr.status = VIRTIO_BLK_S_IOERR; > + if (blk_mq_request_started(rq) && !blk_mq_request_completed(rq)) > + blk_mq_complete_request(rq); > + > + spin_unlock_irqrestore(&vq->lock, flags); > + return true; > +} > + > +/* > + * If the device is broken, it will not use any buffers and waiting > + * for that to happen is pointless. We'll do the cleanup in the driver, > + * completing all requests for the device. > + */ > +static void virtblk_cleanup_broken_device(struct virtio_blk *vblk) > +{ > + struct request_queue *q = vblk->disk->queue; > + > + /* > + * Start freezing the queue, so that new requests keeps waiting at the > + * door of bio_queue_enter(). We cannot fully freeze the queue because > + * frozen queue is an empty queue and there are pending requests, so > + * only start freezing it. > + */ > + blk_freeze_queue_start(q); > + > + /* > + * When quiescing completes, all ongoing dispatches have completed > + * and no new dispatch will happen towards the driver. > + */ > + blk_mq_quiesce_queue(q); > + > + /* > + * Synchronize with any ongoing VQ callbacks that may have started > + * before the VQs were marked as broken. Any outstanding requests > + * will be completed by virtblk_complete_request_with_ioerr(). > + */ > + virtio_synchronize_cbs(vblk->vdev); > + > + /* > + * At this point, no new requests can enter the queue_rq() and > + * completion routine will not complete any new requests either for the > + * broken vq. Hence, it is safe to cancel all requests which are > + * started. > + */ > + blk_mq_tagset_busy_iter(&vblk->tag_set, > + virtblk_complete_request_with_ioerr, vblk); > + blk_mq_tagset_wait_completed_request(&vblk->tag_set); > + > + /* > + * All pending requests are cleaned up. Time to resume so that disk > + * deletion can be smooth. Start the HW queues so that when queue is > + * unquiesced requests can again enter the driver. > + */ > + blk_mq_start_stopped_hw_queues(q, true); > + > + /* > + * Unquiescing will trigger dispatching any pending requests to the > + * driver which has crossed bio_queue_enter() to the driver. > + */ > + blk_mq_unquiesce_queue(q); > + > + /* > + * Wait for all pending dispatches to terminate which may have been > + * initiated after unquiescing. > + */ > + blk_mq_freeze_queue_wait(q); > + > + /* > + * Mark the disk dead so that once we unfreeze the queue, requests > + * waiting at the door of bio_queue_enter() can be aborted right away. > + */ > + blk_mark_disk_dead(vblk->disk); > + > + /* Unfreeze the queue so that any waiting requests will be aborted. */ > + blk_mq_unfreeze_queue_nomemrestore(q); > +} > + > static void virtblk_remove(struct virtio_device *vdev) > { > struct virtio_blk *vblk = vdev->priv; > @@ -1561,6 +1653,9 @@ static void virtblk_remove(struct virtio_device *vdev) > /* Make sure no work handler is accessing the device. */ > flush_work(&vblk->config_work); > > + if (virtqueue_is_broken(vblk->vqs[0].vq)) > + virtblk_cleanup_broken_device(vblk); > + > del_gendisk(vblk->disk); > blk_mq_free_tag_set(&vblk->tag_set); > > -- > 2.34.1 >

4 days, 14 hours

4
20
0 0

[PATCH v3 0/3] Samsung Exynos 7870 DECON driver support

by Kaustabh Chakraborty

This patch series aims at adding support for Exynos7870's DECON in the Exynos7 DECON driver. It introduces a driver data struct so that support for DECON on other SoCs can be added to it in the future. It also fixes a few bugs in the driver, such as functions receiving bad pointers. Tested on Samsung Galaxy J7 Prime (samsung-on7xelte), Samsung Galaxy A2 Core (samsung-a2corelte), and Samsung Galaxy J6 (samsung-j6lte). Signed-off-by: Kaustabh Chakraborty <kauschluss(a)disroot.org> --- Changes in v3: - Add a new commit documenting iommus and ports dt properties. - Link to v2: https://lore.kernel.org/r/20250612-exynosdrm-decon-v2-0-d6c1d21c8057@disroo… Changes in v2: - Add a new commit to prevent an occasional panic under circumstances. - Rewrite and redo [v1 2/6] to be a more sensible commit. - Link to v1: https://lore.kernel.org/r/20240919-exynosdrm-decon-v1-0-6c5861c1cb04@disroo… --- Kaustabh Chakraborty (3): dt-bindings: display: samsung,exynos7-decon: add properties for iommus and ports drm/exynos: exynos7_drm_decon: fix call of decon_commit() drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling .../bindings/display/samsung/samsung,exynos7-decon.yaml | 8 ++++++++ drivers/gpu/drm/exynos/exynos7_drm_decon.c | 8 ++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) --- base-commit: 1b152eeca84a02bdb648f16b82ef3394007a9dcf change-id: 20240917-exynosdrm-decon-4c228dd1d2bf Best regards, -- Kaustabh Chakraborty <kauschluss(a)disroot.org>

4 days, 14 hours

2
5
0 0

[PATCH] drm/gem: Acquire references on GEM handles for framebuffers

by Thomas Zimmermann

A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. The Fixes tag points to commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance"), which triggers the segmentation fault. The issue has been present before. Suggested-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Anusha Srivatsa <asrivats(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> --- drivers/gpu/drm/drm_gem.c | 44 ++++++++++++++++++-- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 +++- drivers/gpu/drm/drm_internal.h | 2 + 3 files changed, 48 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 19d50d254fe6..8be50b3cc9c2 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -213,6 +213,35 @@ void drm_gem_private_object_fini(struct drm_gem_object *obj) } EXPORT_SYMBOL(drm_gem_private_object_fini); +static void drm_gem_object_handle_get(struct drm_gem_object *obj) +{ + struct drm_device *dev = obj->dev; + + drm_WARN_ON(dev, !mutex_is_locked(&dev->object_name_lock)); + + if (obj->handle_count++ == 0) + drm_gem_object_get(obj); +} + +/** + * drm_gem_object_handle_get_unlocked - acquire reference on user-space handles + * @obj: GEM object + * + * Acquires a reference on the GEM buffer object's handle. Required + * to keep the GEM object alive. Call drm_gem_object_handle_put_unlocked() + * to release the reference. + */ +void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj) +{ + struct drm_device *dev = obj->dev; + + guard(mutex)(&dev->object_name_lock); + + drm_WARN_ON(dev, !obj->handle_count); // first ref taken in create-tail helper + drm_gem_object_handle_get(obj); +} +EXPORT_SYMBOL(drm_gem_object_handle_get_unlocked); + /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -243,8 +272,14 @@ static void drm_gem_object_exported_dma_buf_free(struct drm_gem_object *obj) } } -static void -drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) +/** + * drm_gem_object_handle_put_unlocked - releases reference on user-space handles + * @obj: GEM object + * + * Releases a reference on the GEM buffer object's handle. Possibly releases + * the GEM buffer object and associated dma-buf objects. + */ +void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) { struct drm_device *dev = obj->dev; bool final = false; @@ -269,6 +304,7 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) if (final) drm_gem_object_put(obj); } +EXPORT_SYMBOL(drm_gem_object_handle_put_unlocked); /* * Called at device or object close to release the file's @@ -390,8 +426,8 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, int ret; WARN_ON(!mutex_is_locked(&dev->object_name_lock)); - if (obj->handle_count++ == 0) - drm_gem_object_get(obj); + + drm_gem_object_handle_get(obj); /* * Get the user-visible handle using idr. Preload and perform diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index 618ce725cd75..723f1d652c01 100644 --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c @@ -99,8 +99,10 @@ void drm_gem_fb_destroy(struct drm_framebuffer *fb) { unsigned int i; - for (i = 0; i < fb->format->num_planes; i++) + for (i = 0; i < fb->format->num_planes; i++) { + drm_gem_object_handle_put_unlocked(fb->obj[i]); drm_gem_object_put(fb->obj[i]); + } drm_framebuffer_cleanup(fb); kfree(fb); @@ -185,6 +187,7 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev, ret = -ENOENT; goto err_gem_object_put; } + drm_gem_object_handle_get_unlocked(objs[i]); min_size = (height - 1) * mode_cmd->pitches[i] + drm_format_info_min_pitch(info, i, width) @@ -195,6 +198,7 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev, "GEM object size (%zu) smaller than minimum size (%u) for plane %d\n", objs[i]->size, min_size, i); drm_gem_object_put(objs[i]); + drm_gem_object_handle_put_unlocked(objs[i]); ret = -EINVAL; goto err_gem_object_put; } @@ -210,6 +214,7 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev, while (i > 0) { --i; drm_gem_object_put(objs[i]); + drm_gem_object_handle_put_unlocked(objs[i]); } return ret; } diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 442eb31351dd..f7b414a813ae 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -161,6 +161,8 @@ void drm_sysfs_lease_event(struct drm_device *dev); /* drm_gem.c */ int drm_gem_init(struct drm_device *dev); +void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj); +void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj); int drm_gem_handle_create_tail(struct drm_file *file_priv, struct drm_gem_object *obj, u32 *handlep); -- 2.50.0

4 days, 15 hours

2
1
0 0

[PATCH v1 RESEND stable tags] nvmem: layouts: u-boot-env: remove crc32 endianness conversion

by Michael C. Pratt

On 11 Oct 2022, it was reported that the crc32 verification of the u-boot environment failed only on big-endian systems for the u-boot-env nvmem layout driver with the following error. Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) This problem has been present since the driver was introduced, and before it was made into a layout driver. The suggested fix at the time was to use further endianness conversion macros in order to have both the stored and calculated crc32 values to compare always represented in the system's endianness. This was not accepted due to sparse warnings and some disagreement on how to handle the situation. Later on in a newer revision of the patch, it was proposed to use cpu_to_le32() for both values to compare instead of le32_to_cpu() and store the values as __le32 type to remove compilation errors. The necessity of this is based on the assumption that the use of crc32() requires endianness conversion because the algorithm uses little-endian, however, this does not prove to be the case and the issue is unrelated. Upon inspecting the current kernel code, there already is an existing use of le32_to_cpu() in this driver, which suggests there already is special handling for big-endian systems, however, it is big-endian systems that have the problem. This, being the only functional difference between architectures in the driver combined with the fact that the suggested fix was to use the exact same endianness conversion for the values brings up the possibility that it was not necessary to begin with, as the same endianness conversion for two values expected to be the same is expected to be equivalent to no conversion at all. After inspecting the u-boot environment of devices of both endianness and trying to remove the existing endianness conversion, the problem is resolved in an equivalent way as the other suggested fixes. Ultimately, it seems that u-boot is agnostic to endianness at least for the purpose of environment variables. In other words, u-boot reads and writes the stored crc32 value with the same endianness that the crc32 value is calculated with in whichever endianness a certain architecture runs on. Therefore, the u-boot-env driver does not need to convert endianness. Remove the usage of endianness macros in the u-boot-env driver, and change the type of local variables to maintain the same return type. If there is a special situation in the case of endianness, it would be a corner case and should be handled by a unique "compatible". Even though it is not necessary to use endianness conversion macros here, it may be useful to use them in the future for consistent error printing. Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") Reported-by: INAGAKI Hiroshi <musashino.open(a)gmail.com> Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com Cc: <stable(a)vger.kernel.org> # 6.12.x Cc: <stable(a)vger.kernel.org> # 6.6.x: f4cf4e5: Revert "nvmem: add new config option" Cc: <stable(a)vger.kernel.org> # 6.6.x: 7f38b70: of: device: Export of_device_make_bus_id() Cc: <stable(a)vger.kernel.org> # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_get_container() in another header Cc: <stable(a)vger.kernel.org> # 6.6.x: fc29fd8: nvmem: core: Rework layouts to become regular devices Cc: <stable(a)vger.kernel.org> # 6.6.x: 0331c61: nvmem: core: Expose cells through sysfs Cc: <stable(a)vger.kernel.org> # 6.6.x: 401df0d: nvmem: layouts: refactor .add_cells() callback arguments Cc: <stable(a)vger.kernel.org> # 6.6.x: 6d0ca4a: nvmem: layouts: store owner from modules with nvmem_layout_driver_register() Cc: <stable(a)vger.kernel.org> # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env layout Cc: <stable(a)vger.kernel.org> # 6.6.x Signed-off-by: Michael C. Pratt <mcpratt(a)pm.me> --- drivers/nvmem/layouts/u-boot-env.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c index 731e6f4f12b2..21f6dcf905dd 100644 --- a/drivers/nvmem/layouts/u-boot-env.c +++ b/drivers/nvmem/layouts/u-boot-env.c @@ -92,7 +92,7 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, size_t crc32_data_offset; size_t crc32_data_len; size_t crc32_offset; - __le32 *crc32_addr; + uint32_t *crc32_addr; size_t data_offset; size_t data_len; size_t dev_size; @@ -143,8 +143,8 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, goto err_kfree; } - crc32_addr = (__le32 *)(buf + crc32_offset); - crc32 = le32_to_cpu(*crc32_addr); + crc32_addr = (uint32_t *)(buf + crc32_offset); + crc32 = *crc32_addr; crc32_data_len = dev_size - crc32_data_offset; data_len = dev_size - data_offset; base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 -- 2.30.2

4 days, 15 hours

2
1
0 0

[PATCH v2] HID: appletb-kbd: fix memory corruption of input_handler_list

by Qasim Ijaz

In appletb_kbd_probe an input handler is initialised and then registered with input core through input_register_handler(). When this happens input core will add the input handler (specifically its node) to the global input_handler_list. The input_handler_list is central to the functionality of input core and is traversed in various places in input core. An example of this is when a new input device is plugged in and gets registered with input core. The input_handler in probe is allocated as device managed memory. If a probe failure occurs after input_register_handler() the input_handler memory is freed, yet it will remain in the input_handler_list. This effectively means the input_handler_list contains a dangling pointer to data belonging to a freed input handler. This causes an issue when any other input device is plugged in - in my case I had an old PixArt HP USB optical mouse and I decided to plug it in after a failure occurred after input_register_handler(). This lead to the registration of this input device via input_register_device which involves traversing over every handler in the corrupted input_handler_list and calling input_attach_handler(), giving each handler a chance to bind to newly registered device. The core of this bug is a UAF which causes memory corruption of input_handler_list and to fix it we must ensure the input handler is unregistered from input core, this is done through input_unregister_handler(). [ 63.191597] ================================================================== [ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54 [ 63.192094] [ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d [ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164 [ 63.192094] Workqueue: usb_hub_wq hub_event [ 63.192094] Call Trace: [ 63.192094] <TASK> [ 63.192094] dump_stack_lvl+0x53/0x70 [ 63.192094] print_report+0xce/0x670 [ 63.192094] kasan_report+0xce/0x100 [ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] input_register_device+0x76c/0xd00 [ 63.192094] hidinput_connect+0x686d/0xad60 [ 63.192094] hid_connect+0xf20/0x1b10 [ 63.192094] hid_hw_start+0x83/0x100 [ 63.192094] hid_device_probe+0x2d1/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] hid_add_device+0x30b/0x910 [ 63.192094] usbhid_probe+0x920/0xe00 [ 63.192094] usb_probe_interface+0x363/0x9a0 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] usb_set_configuration+0xd14/0x1880 [ 63.192094] usb_generic_driver_probe+0x78/0xb0 [ 63.192094] usb_probe_device+0xaa/0x2e0 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] usb_new_device+0x7b4/0x1000 [ 63.192094] hub_event+0x234d/0x3fa0 [ 63.192094] process_one_work+0x5bf/0xfe0 [ 63.192094] worker_thread+0x777/0x13a0 [ 63.192094] </TASK> [ 63.192094] [ 63.192094] Allocated by task 54: [ 63.192094] kasan_save_stack+0x33/0x60 [ 63.192094] kasan_save_track+0x14/0x30 [ 63.192094] __kasan_kmalloc+0x8f/0xa0 [ 63.192094] __kmalloc_node_track_caller_noprof+0x195/0x420 [ 63.192094] devm_kmalloc+0x74/0x1e0 [ 63.192094] appletb_kbd_probe+0x39/0x440 [ 63.192094] hid_device_probe+0x2d1/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [...] [ 63.192094] [ 63.192094] Freed by task 54: [ 63.192094] kasan_save_stack+0x33/0x60 [ 63.192094] kasan_save_track+0x14/0x30 [ 63.192094] kasan_save_free_info+0x3b/0x60 [ 63.192094] __kasan_slab_free+0x37/0x50 [ 63.192094] kfree+0xcf/0x360 [ 63.192094] devres_release_group+0x1f8/0x3c0 [ 63.192094] hid_device_probe+0x315/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [...] Fixes: 7d62ba8deacf ("HID: hid-appletb-kbd: add support for fn toggle between media and function mode") Cc: stable(a)vger.kernel.org Reviewed-by: Aditya Garg <gargaditya08(a)live.com> Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- v2: - Use correct "Fixes" tag - clean up backtrace by removing "?" entries and a few lower level calls drivers/hid/hid-appletb-kbd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-appletb-kbd.c b/drivers/hid/hid-appletb-kbd.c index d11c49665147..271d1b27b8dd 100644 --- a/drivers/hid/hid-appletb-kbd.c +++ b/drivers/hid/hid-appletb-kbd.c @@ -430,13 +430,15 @@ static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id ret = appletb_kbd_set_mode(kbd, appletb_tb_def_mode); if (ret) { dev_err_probe(dev, ret, "Failed to set touchbar mode\n"); - goto close_hw; + goto unregister_handler; } hid_set_drvdata(hdev, kbd); return 0; +unregister_handler: + input_unregister_handler(&kbd->inp_handler); close_hw: if (kbd->backlight_dev) { put_device(&kbd->backlight_dev->dev); -- 2.39.5

4 days, 17 hours

1
0
0 0

[PATCH] HID: appletb-kbd: fix memory corruption of input_handler_list

by Qasim Ijaz

In appletb_kbd_probe an input handler is initialised and then registered with input core through input_register_handler(). When this happens input core will add the input handler (specifically its node) to the global input_handler_list. The input_handler_list is central to the functionality of input core and is traversed in various places in input core. An example of this is when a new input device is plugged in and gets registered with input core. The input_handler in probe is allocated as device managed memory. If a probe failure occurs after input_register_handler() the input_handler memory is freed, yet it will remain in the input_handler_list. This effectively means the input_handler_list contains a dangling pointer to data belonging to a freed input handler. This causes an issue when any other input device is plugged in - in my case I had an old PixArt HP USB optical mouse and I decided to plug it in after a failure occurred after input_register_handler(). This lead to the registration of this input device via input_register_device which involves traversing over every handler in the corrupted input_handler_list and calling input_attach_handler(), giving each handler a chance to bind to newly registered device. The core of this bug is a UAF which causes memory corruption of input_handler_list and to fix it we must ensure the input handler is unregistered from input core, this is done through input_unregister_handler(). [ 63.191597] ================================================================== [ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54 [ 63.192094] [ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d [ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164 [ 63.192094] Workqueue: usb_hub_wq hub_event [ 63.192094] Call Trace: [ 63.192094] <TASK> [ 63.192094] dump_stack_lvl+0x53/0x70 [ 63.192094] print_report+0xce/0x670 [ 63.192094] ? input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] kasan_report+0xce/0x100 [ 63.192094] ? input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] input_register_device+0x76c/0xd00 [ 63.192094] hidinput_connect+0x686d/0xad60 [ 63.192094] ? __pfx_hidinput_connect+0x10/0x10 [ 63.192094] ? xhci_urb_enqueue+0x523/0x930 [ 63.192094] hid_connect+0xf20/0x1b10 [ 63.192094] ? mutex_unlock+0x7d/0xd0 [ 63.192094] ? __pfx_mutex_unlock+0x10/0x10 [ 63.192094] ? __pm_runtime_idle+0x95/0x1c0 [ 63.192094] ? __pfx_hid_connect+0x10/0x10 [ 63.192094] hid_hw_start+0x83/0x100 [ 63.192094] hid_device_probe+0x2d1/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] ? __pfx___device_attach_driver+0x10/0x10 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] ? __pfx_bus_for_each_drv+0x10/0x10 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] ? __pfx___device_attach+0x10/0x10 [ 63.192094] ? kobject_get+0x50/0xe0 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] ? __pfx_device_add+0x10/0x10 [ 63.192094] ? up_write+0x4d/0x90 [ 63.192094] ? __debugfs_create_file+0x377/0x5a0 [ 63.192094] hid_add_device+0x30b/0x910 [ 63.192094] ? __pfx_hid_add_device+0x10/0x10 [ 63.192094] usbhid_probe+0x920/0xe00 [ 63.192094] ? pm_runtime_enable+0xfa/0x2a0 [ 63.192094] usb_probe_interface+0x363/0x9a0 [ 63.192094] ? sysfs_do_create_link_sd+0x89/0x100 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] ? __pfx___device_attach_driver+0x10/0x10 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] ? __pfx_bus_for_each_drv+0x10/0x10 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] ? __pfx___device_attach+0x10/0x10 [ 63.192094] ? kobject_get+0x50/0xe0 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] ? __pfx_device_add+0x10/0x10 [ 63.192094] ? mutex_unlock+0x7d/0xd0 [ 63.192094] ? __pfx_mutex_unlock+0x10/0x10 [ 63.192094] usb_set_configuration+0xd14/0x1880 [ 63.192094] usb_generic_driver_probe+0x78/0xb0 [ 63.192094] usb_probe_device+0xaa/0x2e0 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] ? usb_generic_driver_match+0x58/0x80 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] ? __pfx___device_attach_driver+0x10/0x10 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] ? __pfx_bus_for_each_drv+0x10/0x10 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] ? __pfx___device_attach+0x10/0x10 [ 63.192094] ? kobject_get+0x50/0xe0 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] ? __pfx_device_add+0x10/0x10 [ 63.192094] ? add_device_randomness+0xb2/0xe0 [ 63.192094] usb_new_device+0x7b4/0x1000 [ 63.192094] hub_event+0x234d/0x3fa0 [ 63.192094] ? __pfx_hub_event+0x10/0x10 [ 63.192094] ? _raw_spin_lock_irqsave+0x85/0xe0 [ 63.192094] ? _raw_spin_lock_irqsave+0x85/0xe0 [ 63.192094] ? mutex_unlock+0x7d/0xd0 [ 63.192094] ? _raw_spin_lock_irq+0x80/0xe0 [ 63.192094] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 63.192094] ? __pm_runtime_suspend+0x74/0x1c0 [ 63.192094] process_one_work+0x5bf/0xfe0 [ 63.192094] worker_thread+0x777/0x13a0 [ 63.192094] ? __kthread_parkme+0x99/0x180 [ 63.192094] ? __pfx_worker_thread+0x10/0x10 [ 63.192094] kthread+0x327/0x630 [ 63.192094] ? __pfx_kthread+0x10/0x10 [ 63.192094] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 63.192094] ? __pfx_kthread+0x10/0x10 [ 63.192094] ? __pfx_kthread+0x10/0x10 [ 63.192094] ret_from_fork+0xff/0x1a0 [ 63.192094] ? __pfx_kthread+0x10/0x10 [ 63.192094] ret_from_fork_asm+0x1a/0x30 [ 63.192094] </TASK> [ 63.192094] [ 63.192094] Allocated by task 54: [ 63.192094] kasan_save_stack+0x33/0x60 [ 63.192094] kasan_save_track+0x14/0x30 [ 63.192094] __kasan_kmalloc+0x8f/0xa0 [ 63.192094] __kmalloc_node_track_caller_noprof+0x195/0x420 [ 63.192094] devm_kmalloc+0x74/0x1e0 [ 63.192094] appletb_kbd_probe+0x39/0x440 [ 63.192094] hid_device_probe+0x2d1/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [...] [ 63.192094] [ 63.192094] Freed by task 54: [ 63.192094] kasan_save_stack+0x33/0x60 [ 63.192094] kasan_save_track+0x14/0x30 [ 63.192094] kasan_save_free_info+0x3b/0x60 [ 63.192094] __kasan_slab_free+0x37/0x50 [ 63.192094] kfree+0xcf/0x360 [ 63.192094] devres_release_group+0x1f8/0x3c0 [ 63.192094] hid_device_probe+0x315/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [...] Fixes: 93a0fc489481 ("HID: hid-appletb-kbd: add support for automatic brightness control while using the touchbar") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- drivers/hid/hid-appletb-kbd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-appletb-kbd.c b/drivers/hid/hid-appletb-kbd.c index d11c49665147..271d1b27b8dd 100644 --- a/drivers/hid/hid-appletb-kbd.c +++ b/drivers/hid/hid-appletb-kbd.c @@ -430,13 +430,15 @@ static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id ret = appletb_kbd_set_mode(kbd, appletb_tb_def_mode); if (ret) { dev_err_probe(dev, ret, "Failed to set touchbar mode\n"); - goto close_hw; + goto unregister_handler; } hid_set_drvdata(hdev, kbd); return 0; +unregister_handler: + input_unregister_handler(&kbd->inp_handler); close_hw: if (kbd->backlight_dev) { put_device(&kbd->backlight_dev->dev); -- 2.39.5

4 days, 17 hours

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror