Received-SPF: pass (google.com: domain of linux-crypto+bounces-2212-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: "Zeng, Xin" <xin.zeng@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
CC: Yishai Hadas <yishaih@nvidia.com>, "herbert@gondor.apana.org.au"
	<herbert@gondor.apana.org.au>, "alex.williamson@redhat.com"
	<alex.williamson@redhat.com>, "shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>, "Tian, Kevin" <kevin.tian@intel.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, qat-linux <qat-linux@intel.com>,
	"Cao, Yahui" <yahui.cao@intel.com>
Subject: RE: [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QAT VF
 devices
Thread-Topic: [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QAT VF
 devices
Thread-Index: AQHaVSVFJ9K0TVMQD0C9btTtb+JmirD9TRgAgAQ3vqCAAHLkgIAC42sAgAhyjxCABghogIAADukQgAAuE4CAAQBLIA==
Date: Wed, 21 Feb 2024 08:44:31 +0000
Message-ID: <DM4PR11MB550223E2A68FA6A95970873888572@DM4PR11MB5502.namprd11.prod.outlook.com>
References: <20240201153337.4033490-1-xin.zeng@intel.com>
 <20240201153337.4033490-11-xin.zeng@intel.com>
 <20240206125500.GC10476@nvidia.com>
 <DM4PR11MB550222F7A5454DF9DBEE7FEC884B2@DM4PR11MB5502.namprd11.prod.outlook.com>
 <20240209121045.GP10476@nvidia.com>
 <e740d9ec-6783-4777-b984-98262566974c@nvidia.com>
 <DM4PR11MB550274B713F6AE416CDF7FDB88532@DM4PR11MB5502.namprd11.prod.outlook.com>
 <20240220132459.GM13330@nvidia.com>
 <DM4PR11MB5502BE3CC8BD098584F31E8D88502@DM4PR11MB5502.namprd11.prod.outlook.com>
 <20240220170315.GO13330@nvidia.com>
In-Reply-To: <20240220170315.GO13330@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m64YW1c09uUEESGSB2fPrREZAriQi3JB8p5PPWpFPoISwh6vI1rxQVi6f2DL?=
 =?us-ascii?Q?DfZb3gKNI2lKuUcYqCezLOegCCRDZLEfTPk+5F02ob0YSIdvTiRtdPjpcEGE?=
 =?us-ascii?Q?be5sTCq1uVtp29+dW9dptoJY39xaUFHnK+Di0FatZwKy3nOObr294daYJYAc?=
 =?us-ascii?Q?8zNcHzSzl1zPQwpSughW65WlJ1fE9nfePQqkqU3nhXoYNwJ1zPidiRr94YEl?=
 =?us-ascii?Q?F+lpUTOk/B3LQwFUDTON9GpIx19FrBz2p+/IcN0zcekn8SsMCueP7LABILFp?=
 =?us-ascii?Q?v9c45ozP8fEBN07wPobtw75p586iNiVAro4EUifrz9hd33OquAsaQrBq0WG0?=
 =?us-ascii?Q?w/X1sgZ+nVj5ruvsVlJ47JQphRNEZRU4vDLzG9rYQzLf7dAQGKpiweFctr/f?=
 =?us-ascii?Q?8YXL1pmGB+ND4Aqc0jFHM2D1vInwm5p9UcF1j8rP1n8hkcVfR+DtT3cHTL3U?=
 =?us-ascii?Q?kbsxYmgUsd0elGuodhRfMjdSRk2U3up/SNGYU6nkVwzDOhdG0Uotixv6v6Gt?=
 =?us-ascii?Q?aAwKNXIVoSUpjAGLzZFdOz801lJmY+w408QNb1uN69LxL5jnmh3Zr+cNT7cr?=
 =?us-ascii?Q?yNbj5darbNcmiHu7n1DrJKuctjV3SoVrVKtqDRHG7fGnEjCcvjoW+/5bHM+Q?=
 =?us-ascii?Q?GtkXgNy7noQzSdVAr6rBWc9MWu319HxToGzvcuZng6mzKABqZnAlMN3w4Y4z?=
 =?us-ascii?Q?C3rH8h5ntm9bCWx8z/Rri4mACBS6f8w+HNdhlpSZ5aZ/pRejajnwoM2nCZYz?=
 =?us-ascii?Q?6p5rV8SPS6zSv6z//eRI1sPcijkgMocx3NxtLtKUcQc59hMphztjx6p9iF1p?=
 =?us-ascii?Q?DKu9ZNgvC4YGLXD2V9OH+8/6GyFiGTOBTmNDeFFHIuuG6m6DjcUbEKtCDAJK?=
 =?us-ascii?Q?I/jDEAn2teRYlK78inIYfi/94u4usiEo090zit4ENq2SRvuYZCfuDXE1ACcv?=
 =?us-ascii?Q?UuI/fhQgZlpJvrp3I6MHEsL3nmnx9IDkILEmKEHIv8vDpStkbngzeIDKm4qT?=
 =?us-ascii?Q?iku28/I0TWtarqATaQai6GYChq8pG+guYPYH2fCRm+klz0PC7sScs1MJ4LW5?=
 =?us-ascii?Q?vkC6MJBri++VD95RL4fEYemVgG/H8rA6c7Dnwe9YBJSWmZoSDTXszfF3jrTK?=
 =?us-ascii?Q?FdsbdGaPicrEofPulgzVVaryR1s2cQfleyu9z6S31FU2sB99fEgpkAcTuTxY?=
 =?us-ascii?Q?CiAq+DWNOimVpMQdWl4Y7XCtXuEiEKMrcb6b5+lGAoIgPYzbqkSV6xahiVJm?=
 =?us-ascii?Q?VOUDERbASLFsHDOVaJSModmK61i5bgKKByIKRMq2O0tVvalvhyS7BbASEw5c?=
 =?us-ascii?Q?1Xjf+ezUi3ttXqpjtERkrU4PaX0BT8iWhIJ8QN+r00AHOJEOULB0Vp1hgg9k?=
 =?us-ascii?Q?6m/2GMVcaEWPWFijiTedfQSTsPS7fR4670vlDkbPYhVeFPOEmLQCULg8jLJC?=
 =?us-ascii?Q?eKdKLvAkX9XNL63VnuTde3c344DgVCX8d5OLUHcRpfTWf4nrRIU+CSj6JkzD?=
 =?us-ascii?Q?bQ+b+VqNfy+o5y5NTyu5Ov65uBzwzA75SukQ4x35MZdpjtFiulsUZoMVoMfe?=
 =?us-ascii?Q?8LlRBk9JlKFszR4KKsQbwmnm3vg8Q+y08WeyAt4m?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-crypto@vger.kernel.org
List-Id: <linux-crypto.vger.kernel.org>
List-Subscribe: <mailto:linux-crypto+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-crypto+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5502.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4b77399-5800-4f99-7930-08dc32b9526b
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2024 08:44:31.2783
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uc0nkSlR8BVMJHQSWMzEqKX1rE+y1HbE6qpGj44dJW32Nac7QB8Qq5MD+iyA774WRLDobygQha2w704PUmDOEg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6132
X-OriginatorOrg: intel.com

On Wednesday, February 21, 2024 1:03 AM, Jason Gunthorpe wrote:
> On Tue, Feb 20, 2024 at 03:53:08PM +0000, Zeng, Xin wrote:
> > On Tuesday, February 20, 2024 9:25 PM, Jason Gunthorpe wrote:
> > > To: Zeng, Xin <xin.zeng@intel.com>
> > > Cc: Yishai Hadas <yishaih@nvidia.com>; herbert@gondor.apana.org.au;
> > > alex.williamson@redhat.com; shameerali.kolothum.thodi@huawei.com;
> Tian,
> > > Kevin <kevin.tian@intel.com>; linux-crypto@vger.kernel.org;
> > > kvm@vger.kernel.org; qat-linux <qat-linux@intel.com>; Cao, Yahui
> > > <yahui.cao@intel.com>
> > > Subject: Re: [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QA=
T VF
> devices
> > >
> > > On Sat, Feb 17, 2024 at 04:20:20PM +0000, Zeng, Xin wrote:
> > >
> > > > Thanks for this information, but this flow is not clear to me why i=
t
> > > > cause deadlock. From this flow, CPU0 is not waiting for any resourc=
e
> > > > held by CPU1, so after CPU0 releases mmap_lock, CPU1 can continue
> > > > to run. Am I missing something?
> > >
> > > At some point it was calling copy_to_user() under the state
> > > mutex. These days it doesn't.
> > >
> > > copy_to_user() would nest the mm_lock under the state mutex which is
> a
> > > locking inversion.
> > >
> > > So I wonder if we still have this problem now that the copy_to_user()
> > > is not under the mutex?
> >
> > In protocol v2, we still have the scenario in precopy_ioctl where
> copy_to_user is
> > called under state_mutex.
>=20
> Why? Does mlx5 do that? It looked Ok to me:
>=20
>         mlx5vf_state_mutex_unlock(mvdev);
>         if (copy_to_user((void __user *)arg, &info, minsz))
>                 return -EFAULT;

Indeed, thanks, Jason. BTW, is there any reason why was "deferred_reset" mo=
de
still implemented in mlx5 driver given this deadlock condition has been avo=
ided
with migration protocol v2 implementation.
Anyway, I'll use state_mutex directly instead of the "deferred_reset" mode =
in qat
variant driver and update it in next version soon, please help to review.
Thanks,
Xin