public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Bastien Curutchet" <bastien.curutchet@bootlin.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	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: Mon, 14 Apr 2025 10:24:55 +0200	[thread overview]
Message-ID: <20250414102455.03331c0f@windsurf> (raw)
In-Reply-To: <Z_yjNgY3dVnA5OVz@infradead.org>

Hello Christoph,

On Sun, 13 Apr 2025 22:55:02 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Apr 10, 2025 at 04:53:17PM +0200, Bastien Curutchet wrote:
> > 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.  
> 
> In which case it does not matter at all for mainline.

It is impressive how "out-of-tree" triggers kernel maintainers, and
then end up not even reading what the patch series is all about (but I
forgive you, because it triggers me in the same way).

This patch series is NOT about adding new kernel APIs meant to be used
by out-of-tree drivers, which of course would be bad, and we would have
never proposed.

What this patch series is about is to add new user-space interface to
extend the existing UIO subsystem. What my colleague Bastien was
mentioning about out-of-tree drivers is that there are a LOT of
out-of-tree drivers extending UIO to allow user-space applications to
do DMA, and our proposal is that considering how many people need that
and implement ugly out-of-tree drivers to solve this issue, we suggest
the mainline kernel should have a built in solution.

Please re-read again, and realize that we are NOT adding new kernel
APIs for out-of-tree drivers.

> FYI the proper and safe way to do DMA from userspace is to use
> vfio/iommufd.

I am not sure how this can work in our use-case. We have a very simple
set of IP blocks implemented in a FPGA, some of those IP blocks are
able to perform DMA operations. The register of those IP blocks are
mapped into a user-space application using the existing, accepted
upstream, UIO subsystem. Some of those registers allow to program DMA
transfers. So far, we can do all what we need, except program those DMA
transfers. Lots of people are having the same issue, and zillions of
ugly out-of-tree solutions flourish all over, and we're trying to see
if we can constructively find a solution that would be acceptable
upstream to resolve this use-case. Our platform is an old PowerPC with
no IOMMU.

Note that the safety argument doesn't hold: UIO already allows to map
registers into user-space applications, which can already program DMA
transfers to arbitrary locations in memory. The safety comes from the
fact that such UIO devices are associated with permissions that the
system administrator controls, to decide which applications are safe
enough to be granted access to those UIO devices. Therefore, providing
access through UIO of the physical address of well-defined DMA buffers
properly allocated through a sane API is not reducing the safety of
anything compared to what UIO already allows today.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

  reply	other threads:[~2025-04-14  9:03 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 ` [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses Christian König
2025-04-10 19:43   ` 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 [this message]
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=20250414102455.03331c0f@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=bastien.curutchet@bootlin.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.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 \
    /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