mbox series

[0/3] uio/dma-buf: Give UIO users access to DMA addresses.

Message ID 20250410-uio-dma-v1-0-6468ace2c786@bootlin.com
Headers show
Series uio/dma-buf: Give UIO users access to DMA addresses. | expand

Message

Bastien Curutchet April 10, 2025, 2:53 p.m. UTC
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.

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.

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.

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,

Comments

Andrew Davis April 14, 2025, 8:13 p.m. UTC | #1
On 4/14/25 2:21 PM, Thomas Petazzoni wrote:
> Hello Andrew,
> 
> On Mon, 14 Apr 2025 12:08:44 -0500
> Andrew Davis <afd@ti.com> wrote:
> 
>> "UIO is a broken legacy mess, so let's add more broken things
>> to it as broken + broken => still broken, so no harm done", am I
>> getting that right?
> 
> Who says UIO is a "broken legacy mess"? Only you says so. I don't see
> any indication anywhere in the kernel tree suggesting that UIO is
> considered a broken legacy mess.
> 

I'm not saying that*, I'm pointing out your argument is that even
though what you are trying to do is broken and unsafe, it is okay to
do because it isn't any "more "broken and unsafe" than UIO already is."

*It is, but that is an argument to have outside of this thread :)

> Keep in mind that when you're running code as root, you can load a
> kernel module, which can do anything on the system security-wise. So
> letting UIO expose MMIO registers of devices to userspace applications
> running as root is not any worse than that.
> 

You can take your computer out back and shoot it too, but we shouldn't
encourage that either :) According to the original docs, UIO was created
to support "industrial I/O cards", think old one-off custom ISA cards by
vendors that had no intention of ever writing a proper driver and just
wanted to poke registers and wait on an IRQ.

IMHO we shouldn't be encouraging that, and trying to modernize UIO does just
that. It gives the impression that is how drivers should still be written.
If you setup your FPGA card to go blink an LED, sure UIO driver it is,
anything more complex, then writing a proper driver is the way to go.

>> If your FPGA IP can do DMA then you should not be using UIO in
>> the first place, see UIO docs:
>>
>>> Please note that UIO is not an universal driver interface. Devices that
>>> are already handled well by other kernel subsystems (like networking or
>>> serial or USB) are no candidates for an UIO driver.
>>
>> The DMA subsystem already handles DMA devices, so write a DMA driver.
> 
> My FPGA IP block is not a DMA controller that would fit the dmaengine
> kernel subsystem. It's a weird custom device that doesn't fit in any
> existing subsystem, and that happens to do "peripheral DMA" (i.e the IP
> block is DMA-capable itself, without relying on a separate DMA
> controller). So this (very valid) recommendation from the UIO
> documentation doesn't apply to my device.

Peripheral DMA is the much more common case, nothing new here. Could
you give a hint as to what this device does that doesn't fit *any*
current subsystem? Or are we talking a hypothetical device (which
for the sake of argument is a valid thing to say, I'm sure with an
FPGA card I could make something that doesn't fit any current
framework too). Just want to know if you are trying to solve a
specific issue or a generic issue here.

Andrew

> 
> Best regards,
> 
> Thomas