Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

27 participants
3100 discussions

[PATCH v2] scsi: lpfc: Fix potential deadlock on &ndlp->lock

by Chengfeng Ye

As &ndlp->lock is acquired by timer lpfc_els_retry_delay() under softirq context, process context code acquiring the lock &ndlp->lock should disable irq or bh, otherwise deadlock could happen if the timer preempt the execution while the lock is held in process context on the same CPU. The two lock acquisition inside lpfc_cleanup_pending_mbox() does not disable irq or softirq. [Deadlock Scenario] lpfc_cmpl_els_fdisc() -> lpfc_cleanup_pending_mbox() -> spin_lock(&ndlp->lock); <irq> -> lpfc_els_retry_delay() -> lpfc_nlp_get() -> spin_lock_irqsave(&ndlp->lock, flags); (deadlock here) This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. The patch fix the potential deadlock by spin_lock_irq() to disable irq. Signed-off-by: Chengfeng Ye <dg573847474(a)gmail.com> --- drivers/scsi/lpfc/lpfc_sli.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 58d10f8f75a7..8555f6bb9742 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -21049,9 +21049,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) mb->mbox_flag |= LPFC_MBX_IMED_UNREG; restart_loop = 1; spin_unlock_irq(&phba->hbalock); - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); spin_lock_irq(&phba->hbalock); break; } @@ -21067,9 +21067,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) ndlp = (struct lpfc_nodelist *)mb->ctx_ndlp; mb->ctx_ndlp = NULL; if (ndlp) { - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); lpfc_nlp_put(ndlp); } } -- 2.17.1

2 years, 3 months

[PATCH] scsi: lpfc: Fix potential deadlock on &ndlp->lock

by Chengfeng Ye

As &ndlp->lock is acquired by timer lpfc_els_retry_delay() under softirq context, process context code acquiring the lock &phba->hbalock should disable irq or bh, otherwise deadlock could happen if the timer preempt the execution while the lock is held in process context on the same CPU. The two lock acquisition inside lpfc_cleanup_pending_mbox() does not disable irq or softirq. [Deadlock Scenario] lpfc_cmpl_els_fdisc() -> lpfc_cleanup_pending_mbox() -> spin_lock(&ndlp->lock); <irq> -> lpfc_els_retry_delay() -> lpfc_nlp_get() -> spin_lock_irqsave(&ndlp->lock, flags); (deadlock here) This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. The patch fix the potential deadlock by spin_lock_irq() to disable irq. Signed-off-by: Chengfeng Ye <dg573847474(a)gmail.com> --- drivers/scsi/lpfc/lpfc_sli.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 58d10f8f75a7..8555f6bb9742 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -21049,9 +21049,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) mb->mbox_flag |= LPFC_MBX_IMED_UNREG; restart_loop = 1; spin_unlock_irq(&phba->hbalock); - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); spin_lock_irq(&phba->hbalock); break; } @@ -21067,9 +21067,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) ndlp = (struct lpfc_nodelist *)mb->ctx_ndlp; mb->ctx_ndlp = NULL; if (ndlp) { - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); lpfc_nlp_put(ndlp); } } -- 2.17.1

2 years, 3 months

[PATCH 0/9] Add DRM driver for StarFive SoC JH7110

by Keith Zhao

Hi, This series is a DRM driver for StarFive SoC JH7110, which includes a display controller driver for Verisilicon DC8200 and an HMDI driver. We use GEM framework for buffer management and allocate memory by using DMA APIs. The JH7110 display subsystem includes a display controller Verisilicon DC8200 and an HDMI transmitter. The HDMI TX IP is designed for transmitting video and audio data from DC8200 to a display device. The HDMI TX IP consists of the digital controller and the physical layer. This series does not support HDMI audio driver. Keith Zhao (9): dt-bindings: display: Add yamls for JH7110 display subsystem riscv: dts: starfive: jh7110: add dc&hdmi controller node drm/verisilicon: Add basic drm driver drm/verisilicon: Add gem driver for JH7110 SoC drm/verisilicon: Add mode config funcs drm/verisilicon: Add drm crtc funcs drm/verisilicon: Add drm plane funcs drm/verisilicon: Add verisilicon dc controller driver drm/verisilicon: Add starfive hdmi driver .../display/verisilicon/starfive-hdmi.yaml | 93 + .../display/verisilicon/verisilicon-dc.yaml | 110 + .../display/verisilicon/verisilicon-drm.yaml | 42 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 9 + .../jh7110-starfive-visionfive-2.dtsi | 87 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 46 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/verisilicon/Kconfig | 24 + drivers/gpu/drm/verisilicon/Makefile | 13 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 928 ++++++++ drivers/gpu/drm/verisilicon/starfive_hdmi.h | 296 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 388 ++++ drivers/gpu/drm/verisilicon/vs_crtc.h | 74 + drivers/gpu/drm/verisilicon/vs_dc.c | 1040 +++++++++ drivers/gpu/drm/verisilicon/vs_dc.h | 62 + drivers/gpu/drm/verisilicon/vs_dc_hw.c | 2008 +++++++++++++++++ drivers/gpu/drm/verisilicon/vs_dc_hw.h | 496 ++++ drivers/gpu/drm/verisilicon/vs_drv.c | 301 +++ drivers/gpu/drm/verisilicon/vs_drv.h | 52 + drivers/gpu/drm/verisilicon/vs_fb.c | 181 ++ drivers/gpu/drm/verisilicon/vs_fb.h | 15 + drivers/gpu/drm/verisilicon/vs_gem.c | 372 +++ drivers/gpu/drm/verisilicon/vs_gem.h | 72 + drivers/gpu/drm/verisilicon/vs_plane.c | 440 ++++ drivers/gpu/drm/verisilicon/vs_plane.h | 74 + drivers/gpu/drm/verisilicon/vs_type.h | 72 + include/uapi/drm/drm_fourcc.h | 83 + include/uapi/drm/vs_drm.h | 50 + 30 files changed, 7433 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml create mode 100644 drivers/gpu/drm/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.c create mode 100644 drivers/gpu/drm/verisilicon/vs_fb.h create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.c create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1

2 years, 3 months

[PATCH 6.1 026/183] dma-buf/dma-resv: Stop leaking on krealloc() failure

by Greg Kroah-Hartman

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. 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 Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.s… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-resv.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -566,6 +566,7 @@ int dma_resv_get_fences(struct dma_resv dma_resv_for_each_fence_unlocked(&cursor, fence) { if (dma_resv_iter_is_restarted(&cursor)) { + struct dma_fence **new_fences; unsigned int count; while (*num_fences) @@ -574,13 +575,17 @@ int dma_resv_get_fences(struct dma_resv count = cursor.num_fences + 1; /* Eventually re-allocate the array */ - *fences = krealloc_array(*fences, count, - sizeof(void *), - GFP_KERNEL); - if (count && !*fences) { + new_fences = krealloc_array(*fences, count, + sizeof(void *), + GFP_KERNEL); + if (count && !new_fences) { + kfree(*fences); + *fences = NULL; + *num_fences = 0; dma_resv_iter_end(&cursor); return -ENOMEM; } + *fences = new_fences; } (*fences)[(*num_fences)++] = dma_fence_get(fence);

2 years, 3 months

[PATCH 6.4 043/227] dma-buf/dma-resv: Stop leaking on krealloc() failure

by Greg Kroah-Hartman

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. 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 Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.s… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-resv.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -571,6 +571,7 @@ int dma_resv_get_fences(struct dma_resv dma_resv_for_each_fence_unlocked(&cursor, fence) { if (dma_resv_iter_is_restarted(&cursor)) { + struct dma_fence **new_fences; unsigned int count; while (*num_fences) @@ -579,13 +580,17 @@ int dma_resv_get_fences(struct dma_resv count = cursor.num_fences + 1; /* Eventually re-allocate the array */ - *fences = krealloc_array(*fences, count, - sizeof(void *), - GFP_KERNEL); - if (count && !*fences) { + new_fences = krealloc_array(*fences, count, + sizeof(void *), + GFP_KERNEL); + if (count && !new_fences) { + kfree(*fences); + *fences = NULL; + *num_fences = 0; dma_resv_iter_end(&cursor); return -ENOMEM; } + *fences = new_fences; } (*fences)[(*num_fences)++] = dma_fence_get(fence);

2 years, 3 months

Patch "dma-buf/dma-resv: Stop leaking on krealloc() failure" has been added to the 6.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma-buf/dma-resv: Stop leaking on krealloc() failure to the 6.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma-buf-dma-resv-stop-leaking-on-krealloc-failure.patch and it can be found in the queue-6.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 05abb3be91d8788328231ee02973ab3d47f5e3d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 13 Jul 2023 22:47:45 +0300 Subject: dma-buf/dma-resv: Stop leaking on krealloc() failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. 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 Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.s… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-resv.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -571,6 +571,7 @@ int dma_resv_get_fences(struct dma_resv dma_resv_for_each_fence_unlocked(&cursor, fence) { if (dma_resv_iter_is_restarted(&cursor)) { + struct dma_fence **new_fences; unsigned int count; while (*num_fences) @@ -579,13 +580,17 @@ int dma_resv_get_fences(struct dma_resv count = cursor.num_fences + 1; /* Eventually re-allocate the array */ - *fences = krealloc_array(*fences, count, - sizeof(void *), - GFP_KERNEL); - if (count && !*fences) { + new_fences = krealloc_array(*fences, count, + sizeof(void *), + GFP_KERNEL); + if (count && !new_fences) { + kfree(*fences); + *fences = NULL; + *num_fences = 0; dma_resv_iter_end(&cursor); return -ENOMEM; } + *fences = new_fences; } (*fences)[(*num_fences)++] = dma_fence_get(fence); Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-6.4/dma-buf-dma-resv-stop-leaking-on-krealloc-failure.patch

2 years, 3 months

Patch "dma-buf/dma-resv: Stop leaking on krealloc() failure" has been added to the 6.1-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma-buf/dma-resv: Stop leaking on krealloc() failure to the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma-buf-dma-resv-stop-leaking-on-krealloc-failure.patch and it can be found in the queue-6.1 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 05abb3be91d8788328231ee02973ab3d47f5e3d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 13 Jul 2023 22:47:45 +0300 Subject: dma-buf/dma-resv: Stop leaking on krealloc() failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. 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 Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.s… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-resv.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -566,6 +566,7 @@ int dma_resv_get_fences(struct dma_resv dma_resv_for_each_fence_unlocked(&cursor, fence) { if (dma_resv_iter_is_restarted(&cursor)) { + struct dma_fence **new_fences; unsigned int count; while (*num_fences) @@ -574,13 +575,17 @@ int dma_resv_get_fences(struct dma_resv count = cursor.num_fences + 1; /* Eventually re-allocate the array */ - *fences = krealloc_array(*fences, count, - sizeof(void *), - GFP_KERNEL); - if (count && !*fences) { + new_fences = krealloc_array(*fences, count, + sizeof(void *), + GFP_KERNEL); + if (count && !new_fences) { + kfree(*fences); + *fences = NULL; + *num_fences = 0; dma_resv_iter_end(&cursor); return -ENOMEM; } + *fences = new_fences; } (*fences)[(*num_fences)++] = dma_fence_get(fence); Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-6.1/dma-buf-dma-resv-stop-leaking-on-krealloc-failure.patch

2 years, 3 months

[PATCH] dma-buf: remove unintended hyphen in the sysfs path

by Luc Ma

From: Luc Ma <luc(a)sietium.com> Signed-off-by: Luc Ma <luc(a)sietium.com> --- drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 6cfbbf0720bd..b5b62e40ccc1 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -33,7 +33,7 @@ * into their address space. This necessitated the creation of the DMA-BUF sysfs * statistics interface to provide per-buffer information on production systems. * - * The interface at ``/sys/kernel/dma-buf/buffers`` exposes information about + * The interface at ``/sys/kernel/dmabuf/buffers`` exposes information about * every DMA-BUF when ``CONFIG_DMABUF_SYSFS_STATS`` is enabled. * * The following stats are exposed by the interface: -- 2.25.1

2 years, 3 months

[PATCH] dma-buf/dma-resv: Stop leaking on krealloc() failure

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. 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 Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/dma-buf/dma-resv.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index b6f71eb00866..38b4110378de 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -571,6 +571,7 @@ int dma_resv_get_fences(struct dma_resv *obj, enum dma_resv_usage usage, dma_resv_for_each_fence_unlocked(&cursor, fence) { if (dma_resv_iter_is_restarted(&cursor)) { + struct dma_fence **new_fences; unsigned int count; while (*num_fences) @@ -579,13 +580,17 @@ int dma_resv_get_fences(struct dma_resv *obj, enum dma_resv_usage usage, count = cursor.num_fences + 1; /* Eventually re-allocate the array */ - *fences = krealloc_array(*fences, count, - sizeof(void *), - GFP_KERNEL); - if (count && !*fences) { + new_fences = krealloc_array(*fences, count, + sizeof(void *), + GFP_KERNEL); + if (count && !new_fences) { + kfree(*fences); + *fences = NULL; + *num_fences = 0; dma_resv_iter_end(&cursor); return -ENOMEM; } + *fences = new_fences; } (*fences)[(*num_fences)++] = dma_fence_get(fence); -- 2.39.3

2 years, 3 months

[PATCH v2 00/24] use vmalloc_array and vcalloc

by Julia Lawall

The functions vmalloc_array and vcalloc were introduced in commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions") but are not used much yet. This series introduces uses of these functions, to protect against multiplication overflows. The changes were done using the following Coccinelle semantic patch. @initialize:ocaml@ @@ let rename alloc = match alloc with "vmalloc" -> "vmalloc_array" | "vzalloc" -> "vcalloc" | _ -> failwith "unknown" @@ size_t e1,e2; constant C1, C2; expression E1, E2, COUNT, x1, x2, x3; typedef u8; typedef __u8; type t = {u8,__u8,char,unsigned char}; identifier alloc = {vmalloc,vzalloc}; fresh identifier realloc = script:ocaml(alloc) { rename alloc }; @@ ( alloc(x1*x2*x3) | alloc(C1 * C2) | alloc((sizeof(t)) * (COUNT), ...) | - alloc((e1) * (e2)) + realloc(e1, e2) | - alloc((e1) * (COUNT)) + realloc(COUNT, e1) | - alloc((E1) * (E2)) + realloc(E1, E2) ) v2: This series uses vmalloc_array and vcalloc instead of array_size. It also leaves a multiplication of a constant by a sizeof as is. Two patches are thus dropped from the series. --- arch/x86/kernel/cpu/sgx/main.c | 2 +- drivers/accel/habanalabs/common/device.c | 3 ++- drivers/accel/habanalabs/common/state_dump.c | 7 ++++--- drivers/bus/mhi/host/init.c | 2 +- drivers/comedi/comedi_buf.c | 4 ++-- drivers/dma-buf/heaps/system_heap.c | 2 +- drivers/gpu/drm/gud/gud_pipe.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 6 ++++-- drivers/infiniband/hw/bnxt_re/qplib_res.c | 4 ++-- drivers/infiniband/hw/erdma/erdma_verbs.c | 4 ++-- drivers/infiniband/sw/siw/siw_qp.c | 4 ++-- drivers/infiniband/sw/siw/siw_verbs.c | 6 +++--- drivers/iommu/tegra-gart.c | 4 ++-- drivers/net/ethernet/amd/pds_core/core.c | 4 ++-- drivers/net/ethernet/freescale/enetc/enetc.c | 4 ++-- drivers/net/ethernet/google/gve/gve_tx.c | 2 +- drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 2 +- drivers/net/ethernet/microsoft/mana/hw_channel.c | 2 +- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 4 ++-- drivers/scsi/fnic/fnic_trace.c | 2 +- drivers/scsi/qla2xxx/qla_init.c | 4 ++-- drivers/vdpa/vdpa_user/iova_domain.c | 4 ++-- drivers/virtio/virtio_mem.c | 6 +++--- fs/btrfs/zoned.c | 4 ++-- kernel/kcov.c | 2 +- lib/test_vmalloc.c | 9 +++++---- 26 files changed, 52 insertions(+), 47 deletions(-)

2 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig