public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leonro@nvidia.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"mgurtovoy@nvidia.com" <mgurtovoy@nvidia.com>,
	liulongfang <liulongfang@huawei.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: [PATCH v3 6/6] hisi_acc_vfio_pci: Add support for VFIO live migration
Date: Mon, 27 Sep 2021 15:32:06 -0300	[thread overview]
Message-ID: <20210927183206.GA1576241@nvidia.com> (raw)
In-Reply-To: <YVINv17OEHplrpeS@unreal>

On Mon, Sep 27, 2021 at 09:30:23PM +0300, Leon Romanovsky wrote:
> On Mon, Sep 27, 2021 at 03:22:24PM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 27, 2021 at 09:17:19PM +0300, Leon Romanovsky wrote:
> > 
> > > > The point is to all out a different locking regime that relies on the
> > > > sriov enable/disable removing the VF struct devices
> > > 
> > > You can't avoid trylock, because this pci_get_sriov_pf_devdata() will be
> > > called in VF where it already holds lock, so attempt to take PF lock
> > > will cause to deadlock.
> > 
> > My whole point is we cannot use the device_lock *at all* and a
> > pci_get_sriov_pf_devdata() would not have it.
> 
> Right
> 
> > 
> > Instead it would have some test to confirm that the 'current' struct
> > device is a VF of the 'target' struct device and thus the drvdata
> > must be valid so long as the 'current' struct device hasn't completed
> > remove.
> 
> I'm curious to see how can you implement it without holding VF lock.

The VF lock is fine, it is the PF lock you can't take

And you don't need the VF lock or the PF lock if it is called in a
context that blocks VF remove() from completing - which describes an
entire VFIO driver.

Jason

  reply	other threads:[~2021-09-27 18:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  9:50 [PATCH v3 0/6] vfio/hisilicon: add acc live migration driver Shameer Kolothum
2021-09-15  9:50 ` [PATCH v3 1/6] crypto: hisilicon/qm: Move the QM header to include/linux Shameer Kolothum
2021-09-15 12:49   ` Jason Gunthorpe
2021-09-15  9:50 ` [PATCH v3 2/6] crypto: hisilicon/qm: Move few definitions to common header Shameer Kolothum
2021-09-15  9:50 ` [PATCH v3 3/6] hisi_acc_qm: Move PCI device IDs " Shameer Kolothum
2021-09-22 15:11   ` Max Gurtovoy
2021-09-24  8:18     ` Shameerali Kolothum Thodi
2021-09-15  9:50 ` [PATCH v3 4/6] hisi-acc-vfio-pci: add new vfio_pci driver for HiSilicon ACC devices Shameer Kolothum
2021-09-15 12:51   ` Jason Gunthorpe
2021-09-15 13:35     ` Shameerali Kolothum Thodi
2021-09-15  9:50 ` [PATCH v3 5/6] hisi_acc_vfio_pci: Restrict access to VF dev BAR2 migration region Shameer Kolothum
2021-09-15  9:50 ` [PATCH v3 6/6] hisi_acc_vfio_pci: Add support for VFIO live migration Shameer Kolothum
2021-09-15 13:07   ` Jason Gunthorpe
2021-09-15 13:28     ` Shameerali Kolothum Thodi
2021-09-16 13:58       ` Jason Gunthorpe
2021-09-27 13:46         ` Shameerali Kolothum Thodi
2021-09-27 15:01           ` Jason Gunthorpe
2021-09-27 15:27             ` Shameerali Kolothum Thodi
2021-09-27 16:00             ` Leon Romanovsky
2021-09-27 16:06               ` Jason Gunthorpe
2021-09-27 18:17                 ` Leon Romanovsky
2021-09-27 18:22                   ` Jason Gunthorpe
2021-09-27 18:30                     ` Leon Romanovsky
2021-09-27 18:32                       ` Jason Gunthorpe [this message]
2021-09-29  3:57 ` [PATCH v3 0/6] vfio/hisilicon: add acc live migration driver Tian, Kevin
2021-09-29  8:34   ` Shameerali Kolothum Thodi
2021-09-29  9:05     ` Tian, Kevin
2021-09-29  9:16       ` Shameerali Kolothum Thodi
2021-09-30  0:42         ` Tian, Kevin
2021-09-30  6:34           ` Shameerali Kolothum Thodi
2021-10-15  5:53             ` Tian, Kevin

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=20210927183206.GA1576241@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liulongfang@huawei.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wangzhou1@hisilicon.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