On Thu, Oct 01, 2026 at 03:38:34PM -0600, Alex Williamson wrote: > On Thu, 24 Sep 2026 16:21:43 +0100 > Matt Evans <[email protected]> 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
