From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9316533CEB7; Fri, 30 Jan 2026 05:43:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769751807; cv=none; b=mRoJ3aLoPqSNgt5PhgU1TSHDlBan4T2Zo7URx6XK7+mdWaWWgeqKPmsjfLERC0hI1328qpniuZwgfmmTJHHB+YiIKi4vyf+TvdgfrRIk3arwzPN6XMkbqz6fo9KIA9UDQNV/iVE6CCRRoWjINkIqFIE7WAn2zJA5z48i2T0LWoE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769751807; c=relaxed/simple; bh=1mj10mAR+dREfsDvfo4M+yfN+P1zHg8E8B5cbP3m5V0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Fko8fCH5zz6UEdGzqCIY78Q73QC33w2MFVpzRZljxa76z8YTlII1H23KG/A6oNl1E7pZA5SNXbLfLQosC+ia+jaEeZb7/lT5WhJNh2wudk8+ImMylTWy5OzIKBzDriwvDn83vNO6wqb5NzMxZ5D6O2Cw1eQcDq1mBAmOR6GAvpE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M2NEkiG3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M2NEkiG3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E00EC4CEF7; Fri, 30 Jan 2026 05:43:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769751807; bh=1mj10mAR+dREfsDvfo4M+yfN+P1zHg8E8B5cbP3m5V0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=M2NEkiG3nXvvzMUybPf9u2NsYSvRQJPu/txpSsJ+Qsxe4sqfutLmoEU01sEJ8CMIg I8qJygosMIvzV8Of29N3Q+NJ4IHqtJpQhzT+fhE6yUEPTeU+erOtBeCAbmFGR6dG/L E41kzSGtTsuhJoFAsbxx660eUE1Lspm74+ePErFMRfookARjIAbj+d5y8bxZjOG3DU tQFiGiDeQxNuiZkSlsQtK41CFeWa6ILJtXkFNDVk30w/Rnxyezaqc8f7v77sWasdlr bW4sKqqCB6eR9qjkzlxTaYVQ4r7qf/9DIoodjgENpnF0X4+qtu5CzCULpCvoHa985+ ryXH1ILEAGAQw== Date: Fri, 30 Jan 2026 06:43:17 +0100 From: Mauro Carvalho Chehab To: "Tian, Kevin" Cc: Jason Gunthorpe , Leon Romanovsky , Pranjal Shrivastava , Sumit Semwal , Christian =?UTF-8?B?S8O2bmln?= , Alex Deucher , "David Airlie" , Simona Vetter , Gerd Hoffmann , Dmitry Osipenko , Gurchetan Singh , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , "Lucas De Marchi" , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?= , "Vivi, Rodrigo" , Joerg Roedel , Will Deacon , Robin Murphy , Felix Kuehling , "Alex Williamson" , Ankit Agrawal , "Kasireddy, Vivek" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-kernel@vger.kernel.org" , "amd-gfx@lists.freedesktop.org" , "virtualization@lists.linux.dev" , "intel-xe@lists.freedesktop.org" , "linux-rdma@vger.kernel.org" , "iommu@lists.linux.dev" , "kvm@vger.kernel.org" Subject: Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete Message-ID: <20260130064317.3c0fead7@foz.lan> In-Reply-To: References: <20260124-dmabuf-revoke-v5-0-f98fca917e96@nvidia.com> <20260124-dmabuf-revoke-v5-4-f98fca917e96@nvidia.com> <20260127085835.GQ13967@unreal> <20260127162754.GH1641016@ziepe.ca> <20260129145851.GE2307128@ziepe.ca> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 30 Jan 2026 03:12:02 +0000 "Tian, Kevin" wrote: > > From: Jason Gunthorpe > > Sent: Thursday, January 29, 2026 10:59 PM > >=20 > > On Thu, Jan 29, 2026 at 07:06:37AM +0000, Tian, Kevin wrote: =20 > > > Bear me if it's an ignorant question. > > > > > > The commit msg of patch6 says that VFIO doesn't tolerate unbounded > > > wait, which is the reason behind the 2nd timeout wait here. =20 > >=20 > > As far as I understand dmabuf design a fence wait should complete > > eventually under kernel control, because these sleeps are > > sprinkled all around the kernel today. > >=20 > > I suspect that is not actually true for every HW, probably something > > like "shader programs can run forever technically". > >=20 > > We can argue if those cases should not report revocable either, but at > > least this will work "correctly" even if it takes a huge amount of > > time. =20 >=20 > good to know those background. >=20 > >=20 > > I wouldn't mind seeing a shorter timeout and print on the fence too > > just in case. > > =20 >=20 > either way is OK. It's not difficult to figure out a long wait anyway. = =F0=9F=98=8A Please don't use Outlook when answering to patches - or ensure that it is properly patched to only send plain text - which I don't think it is possible. If you look on this message source code, it is not in plain text: Content-Type: text/plain; charset=3D"utf-8" Content-Transfer-Encoding: base64 Your message content is: PiBGcm9tOiBKYXNvbiBHdW50aG9ycGUgPGpnZ0B6aWVwZS5jYT4NCj4gU2VudDogVGh1cnNkYX= ks IEphbnVhcnkgMjksIDIwMjYgMTA6NTkgUE0NCj4gDQo+IE9uIFRodSwgSmFuIDI5LCAyMDI2IG= F0 IDA3OjA2OjM3QU0gKzAwMDAsIFRpYW4sIEtldmluIHdyb3RlOg0KPiA+IEJlYXIgbWUgaWYgaX= Qn cyBhbiBpZ25vcmFudCBxdWVzdGlvbi4NCj4gPg0KPiA+IFRoZSBjb21taXQgbXNnIG9mIHBhdG= No NiBzYXlzIHRoYXQgVkZJTyBkb2Vzbid0IHRvbGVyYXRlIHVuYm91bmRlZA0KPiA+IHdhaXQsIH= do aWNoIGlzIHRoZSByZWFzb24gYmVoaW5kIHRoZSAybmQgdGltZW91dCB3YWl0IGhlcmUuDQo+IA= 0K PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGRtYWJ1ZiBkZXNpZ24gYSBmZW5jZSB3YWl0IHNob3= Vs ZCBjb21wbGV0ZQ0KPiBldmVudHVhbGx5IHVuZGVyIGtlcm5lbCBjb250cm9sLCBiZWNhdXNlIH= Ro ZXNlIHNsZWVwcyBhcmUNCj4gc3ByaW5rbGVkIGFsbCBhcm91bmQgdGhlIGtlcm5lbCB0b2RheS= 4N Cj4gDQo+IEkgc3VzcGVjdCB0aGF0IGlzIG5vdCBhY3R1YWxseSB0cnVlIGZvciBldmVyeSBIVy= wg cHJvYmFibHkgc29tZXRoaW5nDQo+IGxpa2UgInNoYWRlciBwcm9ncmFtcyBjYW4gcnVuIGZvcm= V2 ZXIgdGVjaG5pY2FsbHkiLg0KPiANCj4gV2UgY2FuIGFyZ3VlIGlmIHRob3NlIGNhc2VzIHNob3= Vs ZCBub3QgcmVwb3J0IHJldm9jYWJsZSBlaXRoZXIsIGJ1dCBhdA0KPiBsZWFzdCB0aGlzIHdpbG= wg d29yayAiY29ycmVjdGx5IiBldmVuIGlmIGl0IHRha2VzIGEgaHVnZSBhbW91bnQgb2YNCj4gdG= lt ZS4NCg0KZ29vZCB0byBrbm93IHRob3NlIGJhY2tncm91bmQuDQoNCj4gDQo+IEkgd291bGRuJ3= Qg bWluZCBzZWVpbmcgYSBzaG9ydGVyIHRpbWVvdXQgYW5kIHByaW50IG9uIHRoZSBmZW5jZSB0b2= 8N Cj4ganVzdCBpbiBjYXNlLg0KPiANCg0KZWl0aGVyIHdheSBpcyBPSy4gSXQncyBub3QgZGlmZm= lj dWx0IHRvIGZpZ3VyZSBvdXQgYSBsb25nIHdhaXQgYW55d2F5LiDwn5iKDQo=3D which is something that patch tools - in special patchwork - won't handle. Thanks, Mauro