Linaro-mm-sig October 2019

linaro-mm-sig@lists.linaro.org

7 participants
11 discussions

by Christian König

The basic idea stayed the same since the last version of those patches. The exporter can provide explicit pin/unpin functions and the importer a move_notify callback. This allows us to avoid pinning buffers while importers have a mapping for them. In difference to the last version the locking changes were separated from this patchset and committed to drm-misc-next. This allows drivers to implement the new locking semantics without the extra unpinned handling, but of course the changed locking semantics is still a prerequisite to the unpinned handling. The last time this set was send out the discussion ended by questioning if the move_notify callback was really the right approach of notifying the importers that a buffer is about to change its placement. A possible alternative would be to add a special crafted fence object instead. Let's discuss on the different approaches once more, Christian.

4 years, 2 months

[bug report] dma-buf: heaps: Add heap helpers

by Dan Carpenter

Hello John Stultz, The patch 7b87ea704fd9: "dma-buf: heaps: Add heap helpers" from Oct 21, 2019, leads to the following static checker warning: drivers/dma-buf/heaps/heap-helpers.c:165 dma_heap_vm_fault() warn: uncapped user index 'buffer->pages[vmf->pgoff]' drivers/dma-buf/heaps/heap-helpers.c 160 static vm_fault_t dma_heap_vm_fault(struct vm_fault *vmf) 161 { 162 struct vm_area_struct *vma = vmf->vma; 163 struct heap_helper_buffer *buffer = vma->vm_private_data; 164 165 vmf->page = buffer->pages[vmf->pgoff]; ^^^^^^^^^^ Smatch for some reason thinks this needs to be checked. Smatch also gets confused by these fault handlers and thinks there is some recursion involved... 166 get_page(vmf->page); 167 168 return 0; 169 } 170 171 static const struct vm_operations_struct dma_heap_vm_ops = { 172 .fault = dma_heap_vm_fault, 173 }; 174 regards, dan carpenter

4 years, 6 months

Re: [Linaro-mm-sig] [PATCH][next] dma-buf: heaps: remove redundant assignment to variable ret

by John Stultz

On Wed, Oct 30, 2019 at 8:45 AM Andrew F. Davis <afd(a)ti.com> wrote: > > On 10/30/19 11:02 AM, Colin King wrote: > > From: Colin Ian King <colin.king(a)canonical.com> > > > > The variable ret is being assigned with a value that is never > > read, it is being re-assigned the same value on the err0 exit > > path. The assignment is redundant and hence can be removed. > > > > Addresses-Coverity: ("Unused value") > > Fixes: 47a32f9c1226 ("dma-buf: heaps: Add system heap to dmabuf heaps") > > Signed-off-by: Colin Ian King <colin.king(a)canonical.com> > > --- > > > The root of the issue is that ret is not used in the error path, it > should be, I suggest this fix: > > > --- a/drivers/dma-buf/heaps/system_heap.c > > +++ b/drivers/dma-buf/heaps/system_heap.c > > @@ -98,7 +98,7 @@ static int system_heap_allocate(struct dma_heap *heap, > > err0: > > kfree(helper_buffer); > > > > - return -ENOMEM; > > + return ret; > > } Sounds good! If its ok I'll generate a commit crediting Colin for reporting the issue and Andrew for the fix and submit it to Sumit. Many thanks to you both! -john

4 years, 6 months

[PATCH] dma-buf: heaps: Fix redundant assignment to variable ret in system_heap.c

by John Stultz

Colin King reported a coverity error: The variable ret is being assigned with a value that is never read, it is being re-assigned the same value on the err0 exit path. The assignment is redundant and hence can be removed. He had a fix, but Andrew Davis suggested a better solution (actually returning ret), so this patch implements that fix. Cc: Colin King <colin.king(a)canonical.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Andrew F. Davis <afd(a)ti.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: kernel-janitors(a)vger.kernel.org Addresses-Coverity: ("Unused value") Fixes: 47a32f9c1226 ("dma-buf: heaps: Add system heap to dmabuf heaps") Reported-by: Colin Ian King <colin.king(a)canonical.com> Suggested-by: Andrew F. Davis <afd(a)ti.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/dma-buf/heaps/system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 455782efbb32..9a56393e40b4 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -98,7 +98,7 @@ static int system_heap_allocate(struct dma_heap *heap, err0: kfree(helper_buffer); - return -ENOMEM; + return ret; } static const struct dma_heap_ops system_heap_ops = { -- 2.17.1

4 years, 6 months

[PATCH] dma-buf: Fix a warning message in dma_heap_buffer_destroy()

by Dan Carpenter

The first argument of WARN() is a condition so this will just print the function name instead of the whole warning message. Fixes: 7b87ea704fd9 ("dma-buf: heaps: Add heap helpers") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/dma-buf/heaps/heap-helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/heap-helpers.c b/drivers/dma-buf/heaps/heap-helpers.c index 750bef4e902d..a31684c0d5b2 100644 --- a/drivers/dma-buf/heaps/heap-helpers.c +++ b/drivers/dma-buf/heaps/heap-helpers.c @@ -52,7 +52,7 @@ static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer) static void dma_heap_buffer_destroy(struct heap_helper_buffer *buffer) { if (buffer->vmap_cnt > 0) { - WARN("%s: buffer still mapped in the kernel\n", __func__); + WARN(1, "%s: buffer still mapped in the kernel\n", __func__); vunmap(buffer->vaddr); } -- 2.20.1

4 years, 6 months

[PATCH][next] dma-buf: heaps: remove redundant assignment to variable ret

by Colin King

From: Colin Ian King <colin.king(a)canonical.com> The variable ret is being assigned with a value that is never read, it is being re-assigned the same value on the err0 exit path. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Fixes: 47a32f9c1226 ("dma-buf: heaps: Add system heap to dmabuf heaps") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/dma-buf/heaps/system_heap.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 455782efbb32..817a1667bd57 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -55,10 +55,8 @@ static int system_heap_allocate(struct dma_heap *heap, helper_buffer->pages = kmalloc_array(helper_buffer->pagecount, sizeof(*helper_buffer->pages), GFP_KERNEL); - if (!helper_buffer->pages) { - ret = -ENOMEM; + if (!helper_buffer->pages) goto err0; - } for (pg = 0; pg < helper_buffer->pagecount; pg++) { /* -- 2.20.1

4 years, 6 months

[PATCH 1/4] dma-buf: change DMA-buf locking convention v2

by Christian König

This patch is a stripped down version of the locking changes necessary to support dynamic DMA-buf handling. It adds a dynamic flag for both importers as well as exporters so that drivers can choose if they want the reservation object locked or unlocked during mapping of attachments. For compatibility between drivers we cache the DMA-buf mapping during attaching an importer as soon as exporter/importer disagree on the dynamic handling. This change has gone through a lengthy discussion on dri-devel and other mailing lists with at least 3-4 different attempts and dead-ends until we settled on this solution. Please refer to the mailing lists archives for full background on the history of this change. v2: cleanup set_name merge, improve kerneldoc Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-buf.c | 102 +++++++++++++++++++++++++++++++++----- include/linux/dma-buf.h | 57 +++++++++++++++++++-- 2 files changed, 143 insertions(+), 16 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 433d91d710e4..753be84b5fd6 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) size_t ret = 0; dmabuf = dentry->d_fsdata; - mutex_lock(&dmabuf->lock); + dma_resv_lock(dmabuf->resv, NULL); if (dmabuf->name) ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); - mutex_unlock(&dmabuf->lock); + dma_resv_unlock(dmabuf->resv); return dynamic_dname(dentry, buffer, buflen, "/%s:%s", dentry->d_name.name, ret > 0 ? name : ""); @@ -334,7 +334,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) if (IS_ERR(name)) return PTR_ERR(name); - mutex_lock(&dmabuf->lock); + dma_resv_lock(dmabuf->resv, NULL); if (!list_empty(&dmabuf->attachments)) { ret = -EBUSY; kfree(name); @@ -344,7 +344,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) dmabuf->name = name; out_unlock: - mutex_unlock(&dmabuf->lock); + dma_resv_unlock(dmabuf->resv); return ret; } @@ -403,10 +403,10 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) /* Don't count the temporary reference taken inside procfs seq_show */ seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1); seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name); - mutex_lock(&dmabuf->lock); + dma_resv_lock(dmabuf->resv, NULL); if (dmabuf->name) seq_printf(m, "name:\t%s\n", dmabuf->name); - mutex_unlock(&dmabuf->lock); + dma_resv_unlock(dmabuf->resv); } static const struct file_operations dma_buf_fops = { @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return ERR_PTR(-EINVAL); } + if (WARN_ON(exp_info->ops->cache_sgt_mapping && + exp_info->ops->dynamic_mapping)) + return ERR_PTR(-EINVAL); + if (!try_module_get(exp_info->owner)) return ERR_PTR(-ENOENT); @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf) EXPORT_SYMBOL_GPL(dma_buf_put); /** - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally, * calls attach() of dma_buf_ops to allow device-specific attach functionality - * @dmabuf: [in] buffer to attach device to. - * @dev: [in] device to be attached. + * @dmabuf: [in] buffer to attach device to. + * @dev: [in] device to be attached. + * @dynamic_mapping: [in] calling convention for map/unmap * * Returns struct dma_buf_attachment pointer for this attachment. Attachments * must be cleaned up by calling dma_buf_detach(). @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * accessible to @dev, and cannot be moved to a more suitable place. This is * indicated with the error code -EBUSY. */ -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev) +struct dma_buf_attachment * +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, + bool dynamic_mapping) { struct dma_buf_attachment *attach; int ret; @@ -677,6 +683,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, attach->dev = dev; attach->dmabuf = dmabuf; + attach->dynamic_mapping = dynamic_mapping; mutex_lock(&dmabuf->lock); @@ -685,16 +692,64 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, if (ret) goto err_attach; } + dma_resv_lock(dmabuf->resv, NULL); list_add(&attach->node, &dmabuf->attachments); + dma_resv_unlock(dmabuf->resv); mutex_unlock(&dmabuf->lock); + /* When either the importer or the exporter can't handle dynamic + * mappings we cache the mapping here to avoid issues with the + * reservation object lock. + */ + if (dma_buf_attachment_is_dynamic(attach) != + dma_buf_is_dynamic(dmabuf)) { + struct sg_table *sgt; + + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_lock(attach->dmabuf->resv, NULL); + + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); + if (!sgt) + sgt = ERR_PTR(-ENOMEM); + if (IS_ERR(sgt)) { + ret = PTR_ERR(sgt); + goto err_unlock; + } + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_unlock(attach->dmabuf->resv); + attach->sgt = sgt; + attach->dir = DMA_BIDIRECTIONAL; + } + return attach; err_attach: kfree(attach); mutex_unlock(&dmabuf->lock); return ERR_PTR(ret); + +err_unlock: + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_unlock(attach->dmabuf->resv); + + dma_buf_detach(dmabuf, attach); + return ERR_PTR(ret); +} +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach); + +/** + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach + * @dmabuf: [in] buffer to attach device to. + * @dev: [in] device to be attached. + * + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static + * mapping. + */ +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, + struct device *dev) +{ + return dma_buf_dynamic_attach(dmabuf, dev, false); } EXPORT_SYMBOL_GPL(dma_buf_attach); @@ -711,11 +766,20 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (WARN_ON(!dmabuf || !attach)) return; - if (attach->sgt) + if (attach->sgt) { + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_lock(attach->dmabuf->resv, NULL); + dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_unlock(attach->dmabuf->resv); + } + mutex_lock(&dmabuf->lock); + dma_resv_lock(dmabuf->resv, NULL); list_del(&attach->node); + dma_resv_unlock(dmabuf->resv); if (dmabuf->ops->detach) dmabuf->ops->detach(dmabuf, attach); @@ -749,6 +813,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, if (WARN_ON(!attach || !attach->dmabuf)) return ERR_PTR(-EINVAL); + if (dma_buf_attachment_is_dynamic(attach)) + dma_resv_assert_held(attach->dmabuf->resv); + if (attach->sgt) { /* * Two mappings with different directions for the same @@ -761,6 +828,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return attach->sgt; } + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_assert_held(attach->dmabuf->resv); + sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); @@ -793,9 +863,15 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (WARN_ON(!attach || !attach->dmabuf || !sg_table)) return; + if (dma_buf_attachment_is_dynamic(attach)) + dma_resv_assert_held(attach->dmabuf->resv); + if (attach->sgt == sg_table) return; + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_resv_assert_held(attach->dmabuf->resv); + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); @@ -1219,10 +1295,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) seq_puts(s, "\tAttached Devices:\n"); attach_count = 0; + dma_resv_lock(buf_obj->resv, NULL); list_for_each_entry(attach_obj, &buf_obj->attachments, node) { seq_printf(s, "\t%s\n", dev_name(attach_obj->dev)); attach_count++; } + dma_resv_unlock(buf_obj->resv); seq_printf(s, "Total %d devices attached\n\n", attach_count); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index ec212cb27fdc..bcc0f4d0b678 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -42,6 +42,18 @@ struct dma_buf_ops { */ bool cache_sgt_mapping; + /** + * @dynamic_mapping: + * + * If true the framework makes sure that the map/unmap_dma_buf + * callbacks are always called with the dma_resv object locked. + * + * If false the framework makes ure that the map/unmap_dma_buf + * callbacks are always called without the dma_resv object locked. + * Mutual exclusive with @cache_sgt_mapping. + */ + bool dynamic_mapping; + /** * @attach: * @@ -109,6 +121,9 @@ struct dma_buf_ops { * any other kind of sharing that the exporter might wish to make * available to buffer-users. * + * This is always called with the dmabuf->resv object locked when + * the dynamic_mapping flag is true. + * * Returns: * * A &sg_table scatter list of or the backing storage of the DMA buffer, @@ -267,7 +282,8 @@ struct dma_buf_ops { * struct dma_buf - shared buffer object * @size: size of the buffer * @file: file pointer used for sharing buffers across, and for refcounting. - * @attachments: list of dma_buf_attachment that denotes all devices attached. + * @attachments: list of dma_buf_attachment that denotes all devices attached, + * protected by dma_resv lock. * @ops: dma_buf_ops associated with this buffer object. * @lock: used internally to serialize list manipulation, attach/detach and * vmap/unmap, and accesses to name @@ -323,10 +339,12 @@ struct dma_buf { * struct dma_buf_attachment - holds device-buffer attachment data * @dmabuf: buffer for this attachment. * @dev: device attached to the buffer. - * @node: list of dma_buf_attachment. + * @node: list of dma_buf_attachment, protected by dma_resv lock of the dmabuf. * @sgt: cached mapping. * @dir: direction of cached mapping. * @priv: exporter specific attachment data. + * @dynamic_mapping: true if dma_buf_map/unmap_attachment() is called with the + * dma_resv lock held. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -343,6 +361,7 @@ struct dma_buf_attachment { struct list_head node; struct sg_table *sgt; enum dma_data_direction dir; + bool dynamic_mapping; void *priv; }; @@ -394,10 +413,39 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) get_file(dmabuf->file); } +/** + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings. + * @dmabuf: the DMA-buf to check + * + * Returns true if a DMA-buf exporter wants to be called with the dma_resv + * locked, false if it doesn't wants to be called with the lock held. + */ +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) +{ + return dmabuf->ops->dynamic_mapping; +} + +/** + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic + * mappinsg + * @attach: the DMA-buf attachment to check + * + * Returns true if a DMA-buf importer wants to call the map/unmap functions with + * the dma_resv lock held. + */ +static inline bool +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach) +{ + return attach->dynamic_mapping; +} + struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev); + struct device *dev); +struct dma_buf_attachment * +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, + bool dynamic_mapping); void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach); + struct dma_buf_attachment *attach); struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info); @@ -409,6 +457,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction); void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, enum dma_data_direction); +void dma_buf_move_notify(struct dma_buf *dma_buf); int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction dir); int dma_buf_end_cpu_access(struct dma_buf *dma_buf, -- 2.17.1

4 years, 6 months

Dynamic DMA-buf locking changes

by Christian König

Hi everyone, since upstreaming the full dynamic DMA-buf changes turned out more problematic than previously thought I've reverted back to individual patches and separated out only the locking changes. So this patch does NOT contain any new callbacks for pinning/unpinning and move notification, but only the locking changes necessary. As previously discussed when the framework detects that the locking semantics between exporter and importer are different it just falls back to using a cached sgt created during attach time. While separating the patch set I've most likely stumbled over the problem why this previously raised some lockdep warning with i915, it turned out to be just a might_lock() at the wrong place. Please review and/or comment, Christian.

4 years, 6 months

Re: [Linaro-mm-sig] [PATCH] dma-buf/resv: fix exclusive fence get

by Koenig, Christian

Hi Qiang, oh, good point. Yes it certainly should. Looks like I accidentally pushed it to the wrong branch. Thanks, Christian. Am 10.10.19 um 16:27 schrieb Qiang Yu: > Hi Chris, > > This fix has been pushed to drm-misc-next for a while. But Linux > 5.4-rc kernels still does not have this fix. > Should it be also pushed to drm-misc-fixes? > > Thanks, > Qiang > > > On Sun, Sep 22, 2019 at 8:50 PM Chris Wilson <chris(a)chris-wilson.co.uk> wrote: >> Quoting Chris Wilson (2019-09-22 13:17:19) >>> Quoting Qiang Yu (2019-09-22 08:49:00) >>>> This causes kernel crash when testing lima driver. >>>> >>>> Cc: Christian König <christian.koenig(a)amd.com> >>>> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a bit") >>>> Signed-off-by: Qiang Yu <yuq825(a)gmail.com> >>>> --- >>>> drivers/dma-buf/dma-resv.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c >>>> index 42a8f3f11681..709002515550 100644 >>>> --- a/drivers/dma-buf/dma-resv.c >>>> +++ b/drivers/dma-buf/dma-resv.c >>>> @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj, >>>> if (pfence_excl) >>>> *pfence_excl = fence_excl; >>>> else if (fence_excl) >>>> - shared[++shared_count] = fence_excl; >>>> + shared[shared_count++] = fence_excl; >>> Oops. >>> >>> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> >> Applied, thanks for the fix. >> -Chris

4 years, 7 months

Re: [Linaro-mm-sig] [PATCH] dma-buf/resv: fix exclusive fence get

by Daniel Vetter

On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu <yuq825(a)gmail.com> wrote: > > This causes kernel crash when testing lima driver. > > Cc: Christian König <christian.koenig(a)amd.com> > Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a bit") > Signed-off-by: Qiang Yu <yuq825(a)gmail.com> Selftest for this would be lovely, now that the basic infrastructure is in place ... -Daniel > --- > drivers/dma-buf/dma-resv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > index 42a8f3f11681..709002515550 100644 > --- a/drivers/dma-buf/dma-resv.c > +++ b/drivers/dma-buf/dma-resv.c > @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj, > if (pfence_excl) > *pfence_excl = fence_excl; > else if (fence_excl) > - shared[++shared_count] = fence_excl; > + shared[shared_count++] = fence_excl; > > if (!shared_count) { > kfree(shared); > -- > 2.17.1 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

4 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig October 2019