kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"ajones@ventanamicro.com" <ajones@ventanamicro.com>
Subject: Re: [PATCH] vfio: Reuse file f_inode as vfio device inode
Date: Thu, 27 Jun 2024 09:26:34 -0300	[thread overview]
Message-ID: <20240627122634.GJ2494510@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276951FB77A98CBD6CCF79C8CD62@BN9PR11MB5276.namprd11.prod.outlook.com>

On Wed, Jun 26, 2024 at 11:55:59PM +0000, Tian, Kevin wrote:

> > > diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> > > index bb1817bd4ff3..a4eec8e88f5c 100644
> > > --- a/drivers/vfio/device_cdev.c
> > > +++ b/drivers/vfio/device_cdev.c
> > > @@ -40,12 +40,11 @@ int vfio_device_fops_cdev_open(struct inode
> > *inode, struct file *filep)
> > >  	filep->private_data = df;
> > >
> > >  	/*
> > > -	 * Use the pseudo fs inode on the device to link all mmaps
> > > -	 * to the same address space, allowing us to unmap all vmas
> > > -	 * associated to this device using unmap_mapping_range().
> > > +	 * mmaps are linked to the address space of the inode of device cdev.
> > > +	 * Save the inode of device cdev in device->inode to allow
> > > +	 * unmap_mapping_range() to unmap all vmas.
> > >  	 */
> > > -	filep->f_mapping = device->inode->i_mapping;
> > > -
> > > +	device->inode = inode;
> > 
> > This doesn't seem right.. There is only one device but multiple file
> > can be opened on that device.
> > 
> > We expect every open file to have a unique inode otherwise the
> > unmap_mapping_range() will not function properly.
> 
> Does it mean that the existing code is already broken? there is only
> one vfio-fs inode per device (allocated at vfio_init_device()).

I may have gone too far, it is not that we expect evey FD to have a
unique inode, but we expect that there is only one active FD using the
mmap and only that inode will be invalidated.

So changing the inode above before we know that this is an active FD
that can do mmap isn't going to entirely work. ie someone could open
the cdev FD (and fail to make it active) while an active VFIO is using
the legacy path and clobber the invalidation inode.

Having per-FD inodes is just one answer (it is what my similar RDMA
patches were going to do), we could also move the above to the first
mmap so that the one and only active FD also sets the correct inode
for the invalidations.

Jason

  reply	other threads:[~2024-06-27 12:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17  9:53 [PATCH] vfio: Reuse file f_inode as vfio device inode Yan Zhao
2024-06-20 10:14 ` Yan Zhao
2024-06-26  8:36   ` Tian, Kevin
2024-06-26  9:11     ` Yan Zhao
2024-06-26 13:35 ` Jason Gunthorpe
2024-06-26 23:55   ` Tian, Kevin
2024-06-27 12:26     ` Jason Gunthorpe [this message]
2024-06-27  0:17   ` Tian, Kevin
2024-06-27  9:51     ` Yan Zhao
2024-06-27 12:42       ` Jason Gunthorpe
2024-06-28  5:21         ` Yan Zhao
2024-06-28  9:48           ` Yi Liu
2024-06-28 15:28             ` Yan Zhao
2024-06-30  7:06               ` Yi Liu
2024-07-01  1:47                 ` Yan Zhao
2024-07-01  5:44                   ` Yi Liu
2024-07-01  5:48                     ` Yan Zhao
2024-07-10 14:40                       ` Jason Gunthorpe
2024-07-12  5:19                         ` Yan Zhao
2024-07-12  6:14                           ` Yi Liu
2024-07-01  7:54 ` Yi Liu
2024-07-01 11:29   ` Yan Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240627122634.GJ2494510@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ajones@ventanamicro.com \
    --cc=alex.williamson@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=yan.y.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).