public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Bastien Curutchet <bastien.curutchet@bootlin.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.
Date: Thu, 10 Apr 2025 18:29:12 +0200	[thread overview]
Message-ID: <09a5beeb-bae3-4a00-9aff-66adf68064e6@amd.com> (raw)
In-Reply-To: <20250410-uio-dma-v1-0-6468ace2c786@bootlin.com>

Am 10.04.25 um 16:53 schrieb Bastien Curutchet:
> Hi all,
>
> Many UIO users performing DMA from their UIO device need to access the
> DMA addresses of the allocated buffers. There are out-of-tree drivers
> that allow to do it but nothing in the mainline.

Well that basically disqualifies this patch set in the first paragraph.

To justify some kernel change we always need an in kernel user of the interface, since this is purely for out-of-tree drivers this is a no-go to begin with.

> I know DMA shouldn't be handled by userspace but, IMHO, since UIO
> drivers exist, it would be better if they offered a way of doing this.

Leaking DMA addresses to userspace is usually seen as quite some security hole, but on the other hand with UIO you don't have much other choice.

> This patch series use the dma-heap framework which already allows
> userspace to allocate DMA buffers. I tried to avoid 'polluting' the
> existing heaps to prevent inappropriate uses of this new feature by
> introducing a new UIO heap, which is the only one implementing this
> behavior.

Yeah, that won't fly at all.

What you could potentially do is to create an UIO driver which imports DMA-bufs, pins them and then provide the DMA addresses to userspace.

But please be aware that DMA-fences are fundamentally incompatible with UIO. So you won't be able to do any form of synchronization which probably makes the implementation pretty limited.

Regards,
Christian.

>
> PATCH 1 allows the creation of heaps that don't implement map/unmap_buf
> operations as UIO heap doesn't use them.
> PATCH 2 adds the DMA_BUF_IOCTL_GET_DMA_ADDR which transmits the DMA
> addresses to userspace.
> PATCH 3 implements the UIO heap.
>
> It has been tested with the uio_pci_generic driver on a PowerPC.
>
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
> Bastien Curutchet (3):
>       dma-buf: Allow heap that doesn't provide map_buf/unmap_buf
>       dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR
>       uio: Add UIO_DMABUF_HEAP
>
>  drivers/dma-buf/dma-buf.c    |  29 +++++++++--
>  drivers/uio/Kconfig          |   9 ++++
>  drivers/uio/Makefile         |   1 +
>  drivers/uio/uio.c            |   4 ++
>  drivers/uio/uio_heap.c       | 120 +++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-buf.h      |   1 +
>  include/linux/uio_driver.h   |   2 +
>  include/uapi/linux/dma-buf.h |   1 +
>  8 files changed, 164 insertions(+), 3 deletions(-)
> ---
> base-commit: 5f13fa25acaa4f586aaed12efcf7436e004eeaf2
> change-id: 20250408-uio-dma-9b011e9e7f0b
>
> Best regards,


  parent reply	other threads:[~2025-04-10 16:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-10 14:53 [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses Bastien Curutchet
2025-04-10 14:53 ` [PATCH 1/3] dma-buf: Allow heap that doesn't provide map_buf/unmap_buf Bastien Curutchet
2025-04-10 14:53 ` [PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR Bastien Curutchet
2025-04-11 18:34   ` Nicolas Dufresne
2025-04-29  6:39     ` Simona Vetter
2025-04-29  8:12       ` Christian König
2025-04-10 14:53 ` [PATCH 3/3] uio: Add UIO_DMABUF_HEAP Bastien Curutchet
2025-04-11 18:41   ` Nicolas Dufresne
2025-04-10 16:29 ` Christian König [this message]
2025-04-10 19:43   ` [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses Thomas Petazzoni
     [not found]     ` <b596c9af-c0e3-4557-b45a-462a33179235@amd.com>
2025-04-11  8:14       ` Bastien Curutchet
2025-04-11 12:41         ` Christian König
2025-04-14  8:17           ` Thomas Petazzoni
2025-04-14  8:59             ` Christian König
2025-04-14  5:55 ` Christoph Hellwig
2025-04-14  8:24   ` Thomas Petazzoni
2025-04-14  9:11     ` Christian König
2025-04-14 11:52       ` Thomas Petazzoni
2025-04-14 11:24     ` Christoph Hellwig
2025-04-14 11:48       ` Thomas Petazzoni
2025-04-14 17:08         ` Andrew Davis
2025-04-14 19:21           ` Thomas Petazzoni
2025-04-14 20:13             ` Andrew Davis
2025-04-22 18:16             ` Jason Gunthorpe

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=09a5beeb-bae3-4a00-9aff-66adf68064e6@amd.com \
    --to=christian.koenig@amd.com \
    --cc=bastien.curutchet@bootlin.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox