Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

16 participants
3168 discussions

Re: [Linaro-mm-sig] AUTOSEL series truncated was -- Re: [PATCH AUTOSEL 5.15 001/146] dma-buf: WARN on dmabuf release with pending attachments

by Christian König

Hi Pavel, Am 09.11.21 um 08:54 schrieb Pavel Machek: > Hi! > > This series is truncated .. I only got first patches. Similary, 5.10 > series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add > checking to s5p_mfc_probe... is last one I got. > > I got all the patches before that, so I believe it is not problem on > my side, but I'd not mind someone confirming they are seeing the same > problem... It could of course be a different issue, but I've been experiencing similar problems since a couple of weeks now, especially with mailing lists hosted on the freedesktop.org servers and long series of mails. The symptons are that individual mails are missing from a series. I'm usually registered with two completely separated mail accounts (private and work) on those lists and if a mail is missing it is always missing on both accounts. The interesting thing is that if it is a patch set then patchwork (https://patchwork.freedesktop.org/) always seems to get all mails. No idea what's going on here and so far it was to rarely to complain, but with this series it is totally obvious that something is wrong. Regards, Christian. > > Best regards, > Pavel >

4 years

[PATCH AUTOSEL 5.4 01/74] dma-buf: WARN on dmabuf release with pending attachments

by Sasha Levin

From: Charan Teja Reddy <charante(a)codeaurora.org> [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-e… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 758de0e9b2ddc..16bbc9bc9e6d1 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); -- 2.33.0

4 years

[PATCH AUTOSEL 5.10 001/101] dma-buf: WARN on dmabuf release with pending attachments

by Sasha Levin

From: Charan Teja Reddy <charante(a)codeaurora.org> [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-e… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 922416b3aaceb..93e9bf7382595 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); -- 2.33.0

4 years

[PATCH AUTOSEL 5.14 001/138] dma-buf: WARN on dmabuf release with pending attachments

by Sasha Levin

From: Charan Teja Reddy <charante(a)codeaurora.org> [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-e… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a08..733c8b1c8467c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); -- 2.33.0

4 years

[PATCH AUTOSEL 5.15 001/146] dma-buf: WARN on dmabuf release with pending attachments

by Sasha Levin

From: Charan Teja Reddy <charante(a)codeaurora.org> [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-e… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 63d32261b63ff..474de2d988ca7 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -82,6 +82,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); -- 2.33.0

4 years

[PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks

by Michel Dänzer

From: Michel Dänzer <mdaenzer(a)redhat.com> This makes sure we don't hit the BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); in dma_buf_release, which could be triggered by user space closing the dma-buf file description while there are outstanding fence callbacks from dma_buf_poll. Cc: stable(a)vger.kernel.org Signed-off-by: Michel Dänzer <mdaenzer(a)redhat.com> --- drivers/dma-buf/dma-buf.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 6c520c9bd93c..ec25498a971f 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry) BUG_ON(dmabuf->vmapping_counter); /* - * Any fences that a dma-buf poll can wait on should be signaled - * before releasing dma-buf. This is the responsibility of each - * driver that uses the reservation objects. - * - * If you hit this BUG() it means someone dropped their ref to the - * dma-buf while still having pending operation to the buffer. + * If you hit this BUG() it could mean: + * * There's a file reference imbalance in dma_buf_poll / dma_buf_poll_cb or somewhere else + * * dmabuf->cb_in/out.active are non-0 despite no pending fence callback */ BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); @@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) { struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb; + struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll); unsigned long flags; spin_lock_irqsave(&dcb->poll->lock, flags); @@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) dcb->active = 0; spin_unlock_irqrestore(&dcb->poll->lock, flags); dma_fence_put(fence); + /* Paired with get_file in dma_buf_poll */ + fput(dmabuf->file); } static bool dma_buf_poll_shared(struct dma_resv *resv, @@ -278,6 +278,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) spin_unlock_irq(&dmabuf->poll.lock); if (events & EPOLLOUT) { + /* Paired with fput in dma_buf_poll_cb */ + get_file(dmabuf->file); + if (!dma_buf_poll_shared(resv, dcb) && !dma_buf_poll_excl(resv, dcb)) /* No callback queued, wake up any other waiters */ @@ -299,6 +302,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) spin_unlock_irq(&dmabuf->poll.lock); if (events & EPOLLIN) { + /* Paired with fput in dma_buf_poll_cb */ + get_file(dmabuf->file); + if (!dma_buf_poll_excl(resv, dcb)) /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); -- 2.32.0

4 years

Re: [Linaro-mm-sig] [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

by Christian König

Am 29.10.21 um 04:15 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > On Fri, 2021-10-08 at 12:24 +0200, Christian König wrote: >> Am 08.10.21 um 09:54 schrieb guangming.cao(a)mediatek.com: >>> From: Guangming Cao <Guangming.Cao(a)mediatek.com> >>> >>> Because dma-buf.name can be freed in func: "dma_buf_set_name", >>> so, we need to acquire lock first before we read/write dma_buf.name >>> to prevent Use After Free(UAF) issue. >>> >>> Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> >> Reviewed-by: Christian König <christian.koenig(a)amd.com> >> >> Going to push that upstream if nobody else objects. >> >> Thanks, >> Christian. > Just a gentle ping for this patch, please kindly let me know how is it going. Ah, yes. Thanks for the reminder. I've just pushed this to drm-misc-fixes. Christian. > >>> --- >>> drivers/dma-buf/dma-buf.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 511fe0d217a0..a7f6fd13a635 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -1372,6 +1372,8 @@ static int dma_buf_debug_show(struct seq_file >>> *s, void *unused) >>> if (ret) >>> goto error_unlock; >>> >>> + >>> + spin_lock(&buf_obj->name_lock); >>> seq_printf(s, >>> "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n", >>> buf_obj->size, >>> buf_obj->file->f_flags, buf_obj->file- >>>> f_mode, >>> @@ -1379,6 +1381,7 @@ static int dma_buf_debug_show(struct seq_file >>> *s, void *unused) >>> buf_obj->exp_name, >>> file_inode(buf_obj->file)->i_ino, >>> buf_obj->name ?: ""); >>> + spin_unlock(&buf_obj->name_lock); >>> >>> robj = buf_obj->resv; >>> fence = dma_resv_excl_fence(robj); >> >> _______________________________________________ >> Linux-mediatek mailing list >> Linux-mediatek(a)lists.infradead.org >> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr…

4 years

Deploying new iterator interface for dma-buf

by Christian König

Hi guys, a few more bug fixes, looks like the more selftests I add the more odies I find. Assuming the CI tests now pass I will start pushing patches I've already got an rb for to drm-misc-next. Please review and/or comment, Christian.

4 years

Re: [Linaro-mm-sig] [PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Christian König

Am 26.10.21 um 13:52 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > On Tue, 2021-10-26 at 13:18 +0200, Christian König wrote: >> Am 14.10.21 um 12:25 schrieb guangming.cao(a)mediatek.com: >>> From: Guangming Cao <Guangming.Cao(a)mediatek.com> >>> >>> In this patch(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat…;reserved=0), >>> it add a new IOCTL to support dma-buf user to set debug name. >>> >>> But it also added a limitation of this IOCTL, it needs the >>> attachments of dmabuf should be empty, otherwise it will fail. >>> >>> For the original series, the idea was that allowing name change >>> mid-use could confuse the users about the dma-buf. >>> However, the rest of the series also makes sure each dma-buf have a >>> unique >>> inode(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat…;reserved=0), and any >>> accounting >>> should probably use that, without relying on the name as much. >>> >>> So, removing this restriction will let dma-buf userspace users to >>> use it >>> more comfortably and without any side effect. >>> >>> Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> >> We could now cleanup the return value from dma_buf_set_name() into a >> void since that function can't fail any more as far as I can see. >> >> But that isn't mandatory I think, patch is Reviewed-by: Christian >> König >> <christian.koenig(a)amd.com> >> > So, here is no need to check return value of 'strndup_user', > just return without error code if the almost impossible error occurs? Good point, totally missed that one. In that case I'm going to push the patch to drm-misc-next as is. Regards, Christian. > > Guangming. > >> Regards, >> Christian. >> >>> --- >>> drivers/dma-buf/dma-buf.c | 17 +++-------------- >>> 1 file changed, 3 insertions(+), 14 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 511fe0d217a0..5fbb3a2068a3 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file >>> *file, poll_table *poll) >>> >>> /** >>> * dma_buf_set_name - Set a name to a specific dma_buf to track >>> the usage. >>> - * The name of the dma-buf buffer can only be set when the dma-buf >>> is not >>> - * attached to any devices. It could theoritically support >>> changing the >>> - * name of the dma-buf if the same piece of memory is used for >>> multiple >>> - * purpose between different devices. >>> + * It could support changing the name of the dma-buf if the same >>> + * piece of memory is used for multiple purpose between different >>> devices. >>> * >>> * @dmabuf: [in] dmabuf buffer that will be renamed. >>> * @buf: [in] A piece of userspace memory that contains >>> the name of >>> @@ -341,25 +339,16 @@ static __poll_t dma_buf_poll(struct file >>> *file, poll_table *poll) >>> static long dma_buf_set_name(struct dma_buf *dmabuf, const char >>> __user *buf) >>> { >>> char *name = strndup_user(buf, DMA_BUF_NAME_LEN); >>> - long ret = 0; >>> >>> if (IS_ERR(name)) >>> return PTR_ERR(name); >>> >>> - dma_resv_lock(dmabuf->resv, NULL); >>> - if (!list_empty(&dmabuf->attachments)) { >>> - ret = -EBUSY; >>> - kfree(name); >>> - goto out_unlock; >>> - } >>> spin_lock(&dmabuf->name_lock); >>> kfree(dmabuf->name); >>> dmabuf->name = name; >>> spin_unlock(&dmabuf->name_lock); >>> >>> -out_unlock: >>> - dma_resv_unlock(dmabuf->resv); >>> - return ret; >>> + return 0; >>> } >>> >>> static long dma_buf_ioctl(struct file *file, >>

4 years

Re: [Linaro-mm-sig] [PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Christian König

Am 14.10.21 um 12:25 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > In this patch(https://patchwork.freedesktop.org/patch/310349), > it add a new IOCTL to support dma-buf user to set debug name. > > But it also added a limitation of this IOCTL, it needs the > attachments of dmabuf should be empty, otherwise it will fail. > > For the original series, the idea was that allowing name change > mid-use could confuse the users about the dma-buf. > However, the rest of the series also makes sure each dma-buf have a unique > inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting > should probably use that, without relying on the name as much. > > So, removing this restriction will let dma-buf userspace users to use it > more comfortably and without any side effect. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> We could now cleanup the return value from dma_buf_set_name() into a void since that function can't fail any more as far as I can see. But that isn't mandatory I think, patch is Reviewed-by: Christian König <christian.koenig(a)amd.com> Regards, Christian. > --- > drivers/dma-buf/dma-buf.c | 17 +++-------------- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..5fbb3a2068a3 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > /** > * dma_buf_set_name - Set a name to a specific dma_buf to track the usage. > - * The name of the dma-buf buffer can only be set when the dma-buf is not > - * attached to any devices. It could theoritically support changing the > - * name of the dma-buf if the same piece of memory is used for multiple > - * purpose between different devices. > + * It could support changing the name of the dma-buf if the same > + * piece of memory is used for multiple purpose between different devices. > * > * @dmabuf: [in] dmabuf buffer that will be renamed. > * @buf: [in] A piece of userspace memory that contains the name of > @@ -341,25 +339,16 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) > { > char *name = strndup_user(buf, DMA_BUF_NAME_LEN); > - long ret = 0; > > if (IS_ERR(name)) > return PTR_ERR(name); > > - dma_resv_lock(dmabuf->resv, NULL); > - if (!list_empty(&dmabuf->attachments)) { > - ret = -EBUSY; > - kfree(name); > - goto out_unlock; > - } > spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > dmabuf->name = name; > spin_unlock(&dmabuf->name_lock); > > -out_unlock: > - dma_resv_unlock(dmabuf->resv); > - return ret; > + return 0; > } > > static long dma_buf_ioctl(struct file *file,

4 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig