Re: [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 13.10.21 um 01:56 schrieb Sumit Semwal:
Hello Guangming, Christian,



On Tue, 12 Oct 2021, 14:09 , <guangming.cao@xxxxxxxxxxxx> wrote:
From: Guangming Cao <Guangming.Cao@xxxxxxxxxxxx>

> Am 09.10.21 um 07:55 schrieb guangming.cao@xxxxxxxxxxxx:
> From: Guangming Cao <Guangming.Cao@xxxxxxxxxxxx>
> >
> > 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/.
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@xxxxxxxxxxxx>
> > ---
> >   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;
> >   }
> >   


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux