All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Matt Evans <matt@ozlabs.org>, Alex Williamson <alex@shazbot.org>,
	Leon Romanovsky <leon@kernel.org>,
	Jason Gunthorpe <jgg@nvidia.com>, Alex Mastro <amastro@fb.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Pranjal Shrivastava <praan@google.com>,
	Longfang Liu <liulongfang@huawei.com>
Cc: "Mahmoud Adam" <mngyadam@amazon.de>,
	"David Matlack" <dmatlack@google.com>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Ankit Agrawal" <ankita@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v6 3/9] dma-buf: Export dma_buf_set_name()
Date: Mon, 14 Sep 2026 13:06:54 +0200	[thread overview]
Message-ID: <38195919-cdf3-49d4-bf2a-10f6cbab454a@amd.com> (raw)
In-Reply-To: <20260911214200.33793-4-matt@ozlabs.org>

On 9/11/26 23:41, Matt Evans wrote:
> dma_buf_set_name() originally took a __user string to duplicate for
> the buffer name.  Make this function a generic set-name helper, taking
> a kernel-allocated string.
> 
> Wrap this by a new dma_buf_set_name_user() to support the existing
> ioctl path for a user-provided string.

That just describes what the patch does and not why, in other words this needs a bit more justification for the change.

For example something like "Allow exporters/importers to set the name of buffers from pre-existing information".

It is also important to describe which role should set a name (exporter, importer or both). When an exporter gives a standard name for it's buffers that is most likely harmless, but when an importer bluntly overwrites a name previously set by an exporter or userspace then we really need a good reason for that.

> 
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
>  drivers/dma-buf/dma-buf.c | 58 ++++++++++++++++++++++++++++++---------
>  include/linux/dma-buf.h   |  2 ++
>  2 files changed, 47 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d504c636dc29..8129ea11ff58 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,31 +405,29 @@ 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.
> - * It could support changing the name of the dma-buf if the same
> - * piece of memory is used for multiple purpose between different devices.
> + * dma_buf_set_name_user - Set a dma_buf's name from a user string
> + *
> + * The string is up to DMA_BUF_NAME_LEN long, including the terminator.
>   *
>   * @dmabuf: [in]     dmabuf buffer that will be renamed.
>   * @buf:    [in]     A piece of userspace memory that contains the name of
>   *                   the dma-buf.
>   *
> - * Returns 0 on success. If the dma-buf buffer is already attached to
> - * devices, return -EBUSY.
> - *
> + * Returns 0 on success, and any previously-set name is freed.
>   */

Kerneldoc for a static function is usually overkill.

And since this is used only once and very complicated I would completely merge the logic into dma_buf_ioctl().

Regards,
Christian.

> -static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
> +static long dma_buf_set_name_user(struct dma_buf *dmabuf, const char __user *buf)
>  {
>  	char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
> +	int ret;
>  
>  	if (IS_ERR(name))
>  		return PTR_ERR(name);
>  
> -	spin_lock(&dmabuf->name_lock);
> -	kfree(dmabuf->name);
> -	dmabuf->name = name;
> -	spin_unlock(&dmabuf->name_lock);
> +	ret = dma_buf_set_name(dmabuf, name);
> +	if (ret)
> +		kfree(name);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  #if IS_ENABLED(CONFIG_SYNC_FILE)
> @@ -578,7 +576,7 @@ static long dma_buf_ioctl(struct file *file,
>  
>  	case DMA_BUF_SET_NAME_A:
>  	case DMA_BUF_SET_NAME_B:
> -		return dma_buf_set_name(dmabuf, (const char __user *)arg);
> +		return dma_buf_set_name_user(dmabuf, (const char __user *)arg);
>  
>  #if IS_ENABLED(CONFIG_SYNC_FILE)
>  	case DMA_BUF_IOCTL_EXPORT_SYNC_FILE:
> @@ -854,6 +852,40 @@ void dma_buf_put(struct dma_buf *dmabuf)
>  }
>  EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF");
>  
> +/**
> + * dma_buf_set_name - Set a dma_buf's name
> + * 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.
> + * @name:   [in]     The name of the dma-buf, allocated with kmalloc() or
> + *                   similar.  This takes ownership of the allocation
> + *                   on success, which will be kfree()d when the
> + *                   dmabuf is released or a new name assigned.
> + *
> + * Returns 0 on success, -EINVAL if the name is NULL, or -E2BIG if the
> + * name exceeds DMA_BUF_NAME_LEN.
> + */
> +int dma_buf_set_name(struct dma_buf *dmabuf, char *name)
> +{
> +	if (!name)
> +		return -EINVAL;
> +
> +	/* dmabuffs_dname() won't use the string if the length
> +	 * (including terminator) exceeds DMA_BUF_NAME_LEN:
> +	 */
> +	if (strlen(name) >= DMA_BUF_NAME_LEN)
> +		return -E2BIG;
> +
> +	spin_lock(&dmabuf->name_lock);
> +	kfree(dmabuf->name);
> +	dmabuf->name = name;
> +	spin_unlock(&dmabuf->name_lock);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_set_name, "DMA_BUF");
> +
>  static int dma_buf_wrap_sg_table(struct sg_table **sg_table)
>  {
>  	struct scatterlist *to_sg, *from_sg;
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d1203da56fc5..14d3950b63c8 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -570,6 +570,8 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
>  struct dma_buf *dma_buf_get(int fd);
>  void dma_buf_put(struct dma_buf *dmabuf);
>  
> +int dma_buf_set_name(struct dma_buf *dmabuf, char *name);
> +
>  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 *,


  reply	other threads:[~2026-09-14 11:07 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 21:41 [PATCH v6 0/9] vfio/pci: Add mmap() for DMABUFs Matt Evans
2026-09-11 21:41 ` [PATCH v6 1/9] vfio/pci: Remove DMABUF export dependency on vdev->memory_lock Matt Evans
2026-09-11 21:41 ` [PATCH v6 2/9] vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume Matt Evans
2026-09-11 21:41 ` [PATCH v6 3/9] dma-buf: Export dma_buf_set_name() Matt Evans
2026-09-14 11:06   ` Christian König [this message]
2026-09-15 13:35     ` Matt Evans
2026-09-11 21:41 ` [PATCH v6 4/9] vfio/pci: Add a helper to look up PFNs for DMABUFs Matt Evans
2026-09-11 21:41 ` [PATCH v6 5/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Matt Evans
2026-09-15 12:16   ` liulongfang
2026-09-21 13:24     ` Matt Evans
2026-09-22  9:16       ` liulongfang
2026-09-24 12:43         ` Matt Evans
2026-09-11 21:41 ` [PATCH v6 6/9] vfio/pci: Convert BAR mmap() to use a DMABUF Matt Evans
2026-09-11 21:41 ` [PATCH v6 7/9] vfio/pci: Clean up BAR zap and revocation Matt Evans
2026-09-11 21:41 ` [PATCH v6 8/9] vfio/pci: Support mmap() of a VFIO DMABUF Matt Evans
2026-09-11 21:41 ` [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request Matt Evans
2026-09-13 16:52   ` Leon Romanovsky
2026-09-14 11:36     ` Jason Gunthorpe
2026-09-14 11:54       ` Leon Romanovsky
2026-09-14 11:58         ` Jason Gunthorpe
2026-09-14 12:06           ` Leon Romanovsky
2026-09-14 12:08             ` Jason Gunthorpe
2026-09-14 12:13         ` Matt Evans
2026-09-15  7:20           ` Leon Romanovsky
2026-09-15 11:13             ` Christian König
2026-09-15 14:22               ` Matt Evans
2026-09-16 14:19                 ` Christian König
2026-09-21 13:08                   ` Matt Evans
2026-09-21 13:22                     ` Jason Gunthorpe
2026-09-21 13:45                       ` Christian König
2026-09-21 13:49                         ` Jason Gunthorpe
2026-09-21 14:09                           ` Christian König
2026-09-22 12:41                             ` Jason Gunthorpe
2026-09-22 12:46                               ` Leon Romanovsky
2026-09-22 12:54                                 ` Jason Gunthorpe
2026-09-22 22:31                                   ` Alex Mastro
2026-09-22 22:57                                     ` Jason Gunthorpe
2026-09-23 15:40                                       ` Matt Evans
2026-09-23 16:13                                         ` Jason Gunthorpe
2026-09-23 16:52                                         ` Leon Romanovsky
2026-09-23 17:06                                           ` Matt Evans
2026-09-24 17:36                                       ` Alex Mastro
2026-09-22 11:40                     ` Leon Romanovsky
2026-09-15 12:35           ` Jason Gunthorpe
2026-09-15 14:30             ` Matt Evans

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=38195919-cdf3-49d4-bf2a-10f6cbab454a@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alex@shazbot.org \
    --cc=amastro@fb.com \
    --cc=ankita@nvidia.com \
    --cc=apopple@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn@kernel.org \
    --cc=dmatlack@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liulongfang@huawei.com \
    --cc=logang@deltatee.com \
    --cc=matt@ozlabs.org \
    --cc=mngyadam@amazon.de \
    --cc=praan@google.com \
    --cc=sumit.semwal@linaro.org \
    --cc=vivek.kasireddy@intel.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.