Re: [LSF/MM/BPF TOPIC] dmabuf backed read/write

["Christian König" <christian.koenig@amd.com>]

On 2/9/26 14:24, Jason Gunthorpe wrote:
> On Mon, Feb 09, 2026 at 02:09:24PM +0100, Christian König wrote:
> 
>> We have exercised and discussed this in absolutely detail and it is
>> not going to fly anywhere.
> 
> Yes, I understand you concerns with struct page from past abuses.
>  
>> The struct page based approach in fundamentally incompatible with
>> driver managed exporters.
> 
> The *general* struct page system is incompatible - but that is not
> what I'm suggesting. I'm suggesting io_uring, and only io_uring could
> use this with it fully implementing all the lifecycle rules that are
> needed.  Including move_notify and fences so that the driver managed
> exporter has no issue.

Yeah, that is basically what everybody currently does with out of tree code.

The problem is that this requires internal knowledge of the exported buffer and how the I/O path is using it.

So to generalize this for upstreaming it would need something like a giant whitelist of exporter/importer combinations which are known to work together and not crash the kernel in surprising and hard to track down ways.

I had this conversation multiple times with both AMD internal as well as external people and just using an exporter specific io_uring (or whatever approach the exporter uses) implementation is just simpler.

> Reworking the block stack to not rely on page is also a good path, but
> probably alot harder. :\

Yeah, that would be really really nice to have and the latest patches for extending the struct file stuff actually looked quite promising.

Christian.

> 
> Jason