lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250410214307.361e373f@windsurf>
Date: Thu, 10 Apr 2025 21:43:07 +0200
From: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
To: Christian König <christian.koenig@....com>
Cc: Bastien Curutchet <bastien.curutchet@...tlin.com>, Sumit Semwal
 <sumit.semwal@...aro.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA
 addresses.

Hello Christian,

Thanks for your feedback!

On Thu, 10 Apr 2025 18:29:12 +0200
Christian König <christian.koenig@....com> wrote:

> > 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'm not sure to understand your comment here. This patch series is
about extending the UIO interface... which is a user-space interface.
So obviously it has no "in-kernel user" because it's meant to be used
from user-space. Could you clarify what you meant here?


> 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.

Could you clarify why DMA-fences would be needed here, and for what
synchronization?

The DMA buffers allocated here are DMA coherent buffers. So the
user-space application that uses UIO will allocate such buffers once at
application start, retrieve their DMA address, and then program DMA
transfers as it sees fit using the memory-mapped registers accessible
through UIO. I'm not sure which synchronization you are referring to.
We are not "chaining" DMA transfers, with for example a camera
interface feeding its DMA buffers to an ISP or something like that. The
typical use case here is some IP block in an FPGA that does DMA
transfers to transfer data to/from some sort of specialized I/O
interface. We get an interrupt when the transfer is done, and we can
re-use the buffer for the next transfer.

If you could clarify here as well, it would definitely help in
understanding the shortcomings/limitations.

Thanks a lot!

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ