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