On Mon, Jul 07, 2025 at 04:41:23PM +0100, Pavel Begunkov wrote:

...

I mean a reference the actual dma_buf (probably indirect through the file

• for it, but listen to the dma_buf experts for that and not me).

My expectation is that io_uring would pass struct dma_buf to the

io_uring isn't the only user. We've already had one other use case coming up for pre-load of media files in mobile very recently. It's also a really good interface for P2P transfers of any kind.

file during registration, so that it can do a bunch of work upfront, but iterators will carry sth already pre-attached and pre dma mapped, probably in a file specific format hiding details for multi-device support, and possibly bundled with the dma-buf pointer if necessary. (All modulo move notify which I need to look into first).

I'd expect that the exported passed around the dma_buf, and something that has access to it then imports it to the file. This could be directly forwarded to the device for the initial scrope in your series where you only support it for block device files.

Now we have two variants:

1) the file instance returns a cookie for the registration that the caller has to pass into every read/write 2) the file instance tracks said cookie itself and matches it on every read/write

1) sounds faster, 2) has more sanity checking and could prevent things from going wrong.

(all this is based on my limited dma_buf understanding, corrections always welcome).

...

...

But maybe that's fine. It's 40B -> 48B,

Alternatively we could the union point to a struct that has the dma buf pointer and a variable length array of dma_segs. Not sure if that would create a mess in the callers, though.

Iteration helpers adjust the pointer, so either it needs to store the pointer directly in iter or keep the current index. It could rely solely on offsets, but that'll be a mess with nested loops (where the inner one would walk some kind of sg table).

Yeah. Maybe just keep is as a separate pointer growing the structure and see if anyone screams.