From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Cornelia Huck <cohuck@redhat.com>, Christoph Hellwig <hch@lst.de>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Longfang Liu <liulongfang@huawei.com>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH] vfio/pci: Remove vfio_device_get_from_dev()
Date: Tue, 26 Apr 2022 08:55:35 -0300 [thread overview]
Message-ID: <20220426115535.GK2125828@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276C7829513E8477DE7BBDB8CFB9@BN9PR11MB5276.namprd11.prod.outlook.com>
On Tue, Apr 26, 2022 at 03:51:13AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Tuesday, April 26, 2022 7:01 AM
> >
> > The last user of this function is in PCI callbacks that want to convert
> > their struct pci_dev to a vfio_device. Instead of searching use the
> > vfio_device available trivially through the drvdata.
> >
> > When a callback in the device_driver is called, the caller must hold the
> > device_lock() on dev. The purpose of the device_lock is to prevent
> > remove() from being called (see __device_release_driver), and allow the
> > driver to safely interact with its drvdata without races.
> >
> > The PCI core correctly follows this and holds the device_lock() when
> > calling error_detected (see report_error_detected) and
> > sriov_configure (see sriov_numvfs_store).
>
> Above is clear for the change in this patch.
>
> >
> > Further, since the drvdata holds a positive refcount on the vfio_device
> > any access of the drvdata, under the driver_lock, from a driver callback
> > needs no further protection or refcounting.
>
> but I'm confused by driver_lock here and below. Which driver_lock is
> referred to in this context?
That is a typo, it should be device_lock
> > Thus the remark in the vfio_device_get_from_dev() comment does not apply
> > here, VFIO PCI drivers all call vfio_unregister_group_dev() from their
> > remove callbacks under the driver lock and cannot race with the remaining
> > callers.
> >
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
>
> Nevertheless, this patch sounds the correct thing to do:
>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>
> but with one nit...
>
> [...]
> > @@ -1960,8 +1942,7 @@ int vfio_pci_core_sriov_configure(struct pci_dev
> > *pdev, int nr_virtfn)
> > ret = pci_enable_sriov(pdev, nr_virtfn);
> > if (ret)
> > goto out_del;
> > - ret = nr_virtfn;
> > - goto out_put;
> > + return ret;
>
> pci_enable_sriov() returns 0 on success while .sriov_configure()
> is expected to return enabled nr_virtfn on success. Above changes
> the semantics.
Arg, I botched it when rebasing over the final version of the rc
patch.. Thanks!
Jason
prev parent reply other threads:[~2022-04-26 11:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 23:01 [PATCH] vfio/pci: Remove vfio_device_get_from_dev() Jason Gunthorpe
2022-04-26 3:51 ` Tian, Kevin
2022-04-26 11:55 ` Jason Gunthorpe [this message]
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=20220426115535.GK2125828@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=hch@lst.de \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yishaih@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.