All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Sumit Semwal <sumit.semwal@linaro.org>, guangming.cao@mediatek.com
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>,
	Linaro MM SIG <linaro-mm-sig@lists.linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>,
	linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
	Randy Dunlap <rdunlap@infradead.org>,
	wsd_upstream@mediatek.com
Subject: Re: [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
Date: Wed, 13 Oct 2021 14:20:53 +0200	[thread overview]
Message-ID: <236a6cf9-3eb7-9315-4dd9-c1522be56c7e@amd.com> (raw)
In-Reply-To: <CAO_48GE_jCWY4waK-+FqVw5sbuoHddt4kWpnkpvyLDRC__yE+g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5037 bytes --]

Am 13.10.21 um 01:56 schrieb Sumit Semwal:
> Hello Guangming, Christian,
>
>
>
> On Tue, 12 Oct 2021, 14:09 , <guangming.cao@mediatek.com 
> <mailto:guangming.cao@mediatek.com>> wrote:
>
>     From: Guangming Cao <Guangming.Cao@mediatek.com
>     <mailto:Guangming.Cao@mediatek.com>>
>
>     > Am 09.10.21 um 07:55 schrieb guangming.cao@mediatek.com
>     <mailto:guangming.cao@mediatek.com>:
>     > From: Guangming Cao <Guangming.Cao@mediatek.com
>     <mailto:Guangming.Cao@mediatek.com>>
>     > >
>     > > If dma-buf don't want userspace users to touch the dmabuf buffer,
>     > > it seems we should add this restriction into dma_buf_ops.mmap,
>     > > not in this IOCTL:DMA_BUF_SET_NAME.
>     > >
>     > > With this restriction, we can only know the kernel users of
>     the dmabuf
>     > > by attachments.
>     > > However, for many userspace users, such as userpsace users of
>     dma_heap,
>     > > they also need to mark the usage of dma-buf, and they don't
>     care about
>     > > who attached to this dmabuf, and seems it's no meaning to be
>     waiting for
>     > > IOCTL:DMA_BUF_SET_NAME rather than mmap.
>     >
>     > Sounds valid to me, but I have no idea why this restriction was
>     added in
>     > the first place.
>     >
>     > Can you double check the git history and maybe identify when
>     that was
>     > added? Mentioning this change in the commit message then might make
>     > things a bit easier to understand.
>     >
>     > Thanks,
>     > Christian.
>     It was add in this patch:
>     https://patchwork.freedesktop.org/patch/310349/
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F310349%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C4149923e2b0646de82ce08d98ddbf2c2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637696798278342557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N49RVF4s%2BGQ4D%2Ft1MOwRsCnslFnwobSB3G86pvP9m7A%3D&reserved=0>.
>     However, there is no illustration about it.
>     I guess it wants users to set_name when no attachments on the dmabuf,
>     for case with attachments, we can find owner by device in attachments.
>     But just I said in commit message, this is might not a good idea.
>
>     Do you have any idea?
>
>
> 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, and 
> any accounting should probably use that, without relying on the name 
> as much.
> So I don't have an objection to this change.

I suggest to add that explanation and the original commit id into the 
commit message.

With that changed the patch has my rb as well.

Regards,
Christian.

>
> Best,
> Sumit.
>
>     >
>     > >
>     > > Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com
>     <mailto:Guangming.Cao@mediatek.com>>
>     > > ---
>     > >   drivers/dma-buf/dma-buf.c | 14 ++------------
>     > >   1 file changed, 2 insertions(+), 12 deletions(-)
>     > >
>     > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>     > > index 511fe0d217a0..db2f4efdec32 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 theoretically 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
>     > > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct
>     dma_buf *dmabuf, const char __user *buf)
>     > >     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;
>     > >   }
>     > >
>


[-- Attachment #2: Type: text/html, Size: 9308 bytes --]

  reply	other threads:[~2021-10-13 12:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-09  2:47 [PATCH] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME guangming.cao
2021-10-09  2:47 ` guangming.cao
2021-10-09  2:47 ` guangming.cao
2021-10-09  4:41 ` Randy Dunlap
2021-10-09  4:41   ` Randy Dunlap
2021-10-09  4:41   ` Randy Dunlap
2021-10-09  5:55   ` [PATCH v2] " guangming.cao
2021-10-09  5:55     ` guangming.cao
2021-10-09  5:55     ` guangming.cao
2021-10-11  8:20     ` Christian König
2021-10-11  8:20       ` Christian König
2021-10-11  8:20       ` Christian König
2021-10-12  8:41       ` guangming.cao
2021-10-12  8:41         ` guangming.cao
2021-10-12  8:41         ` guangming.cao
2021-10-12 23:56         ` Sumit Semwal
2021-10-13 12:20           ` Christian König [this message]
2021-10-14 10:25         ` [PATCH v3] " guangming.cao
2021-10-14 10:25           ` guangming.cao
2021-10-14 10:25           ` guangming.cao
2021-10-14 10:35           ` guangming.cao
2021-10-14 10:35             ` guangming.cao
2021-10-14 10:35             ` guangming.cao
2021-10-26  8:04           ` guangming.cao
2021-10-26  8:04             ` guangming.cao
2021-10-26  8:04             ` guangming.cao
2021-10-26 11:18           ` Christian König
2021-10-26 11:18             ` Christian König
2021-10-26 11:18             ` Christian König
2021-10-26 11:52             ` guangming.cao
2021-10-26 11:52               ` guangming.cao
2021-10-26 11:52               ` guangming.cao
2021-10-28 11:35               ` Christian König
2021-10-28 11:35                 ` Christian König
2021-10-28 11:35                 ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=236a6cf9-3eb7-9315-4dd9-c1522be56c7e@amd.com \
    --to=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guangming.cao@mediatek.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=sumit.semwal@linaro.org \
    --cc=wsd_upstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.