Re: [PATCH v7 0/9] vfio/pci: Add mmap() for DMABUFs

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Oct 01, 2026 at 03:38:34PM -0600, Alex Williamson wrote:
> On Thu, 24 Sep 2026 16:21:43 +0100
> Matt Evans <matt@ozlabs.org> wrote:
> > Dear Reviewers,
> > ===============
> > 
> > Along the way several related issues came up that warrant more
> > eyes, and I'd be grateful for your input:
> > 
> > 1. If VFIO fd is opened O_RDONLY, it currently can't be mmap()ed
> >    (because PROT_WRITE is rejected in do_mmap(), and PROT_READ alone
> >    drops the VM_SHARED so VFIO's mmap rejects it).  BUT it seems we
> >    can export a DMABUF from it, and then pass the resulting fd around
> >    for P2P writes.
> > 
> >    I don't know if this is intentional/relied on/a known limitation,
> >    or a bug?
> 
> Seems like a bug.  In practice it's probably not very meaningful, the
> user can still potentially change the device power state and trigger a
> reset, but being able to source a writable dmabuf to a region on the
> device fd that isn't itself writable seems semantically wrong.

I'm shocked O_RDONLY even did *anything*, I never expected this.

IMHO with these kinds of cdev's we shouldn't do anything in response
to O_RDONLY. If the core code does something then fine, but I don't
think we should try to define a semantic what "Read only vfio" even
should mean.

> >    a) We could reject export w/ -EPERM unless the device fd's f_mode
> >       has O_RDWR, to reflect the RW abilities of P2P
> 
> This seems sufficient...

+1

Jason