linux-kernel - Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260130064317.3c0fead7@foz.lan>
Date: Fri, 30 Jan 2026 06:43:17 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>,
 Pranjal Shrivastava <praan@...gle.com>, Sumit Semwal
 <sumit.semwal@...aro.org>, Christian König
 <christian.koenig@....com>, Alex Deucher <alexander.deucher@....com>,
 "David Airlie" <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Gerd
 Hoffmann <kraxel@...hat.com>, Dmitry Osipenko
 <dmitry.osipenko@...labora.com>, Gurchetan Singh
 <gurchetansingh@...omium.org>, Chia-I Wu <olvaffe@...il.com>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, "Lucas De
 Marchi" <lucas.demarchi@...el.com>, Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>, "Vivi, Rodrigo"
 <rodrigo.vivi@...el.com>, Joerg Roedel <joro@...tes.org>, Will Deacon
 <will@...nel.org>, Robin Murphy <robin.murphy@....com>, Felix Kuehling
 <Felix.Kuehling@....com>, "Alex Williamson" <alex@...zbot.org>, Ankit
 Agrawal <ankita@...dia.com>, "Kasireddy, Vivek"
 <vivek.kasireddy@...el.com>, "linux-media@...r.kernel.org"
 <linux-media@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
 <dri-devel@...ts.freedesktop.org>, "linaro-mm-sig@...ts.linaro.org"
 <linaro-mm-sig@...ts.linaro.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "amd-gfx@...ts.freedesktop.org"
 <amd-gfx@...ts.freedesktop.org>, "virtualization@...ts.linux.dev"
 <virtualization@...ts.linux.dev>, "intel-xe@...ts.freedesktop.org"
 <intel-xe@...ts.freedesktop.org>, "linux-rdma@...r.kernel.org"
 <linux-rdma@...r.kernel.org>, "iommu@...ts.linux.dev"
 <iommu@...ts.linux.dev>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete

On Fri, 30 Jan 2026 03:12:02 +0000
"Tian, Kevin" <kevin.tian@...el.com> wrote:

> > From: Jason Gunthorpe <jgg@...pe.ca>
> > Sent: Thursday, January 29, 2026 10:59 PM
> > 
> > On Thu, Jan 29, 2026 at 07:06:37AM +0000, Tian, Kevin wrote:  
> > > 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.  
> > 
> > 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.
> > 
> > I suspect that is not actually true for every HW, probably something
> > like "shader programs can run forever technically".
> > 
> > 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.  
> 
> good to know those background.
> 
> > 
> > I wouldn't mind seeing a shorter timeout and print on the fence too
> > just in case.
> >   
> 
> either way is OK. It's not difficult to figure out a long wait anyway. 😊

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="utf-8"
	Content-Transfer-Encoding: base64

Your message content is:

	PiBGcm9tOiBKYXNvbiBHdW50aG9ycGUgPGpnZ0B6aWVwZS5jYT4NCj4gU2VudDogVGh1cnNkYXks
	IEphbnVhcnkgMjksIDIwMjYgMTA6NTkgUE0NCj4gDQo+IE9uIFRodSwgSmFuIDI5LCAyMDI2IGF0
	IDA3OjA2OjM3QU0gKzAwMDAsIFRpYW4sIEtldmluIHdyb3RlOg0KPiA+IEJlYXIgbWUgaWYgaXQn
	cyBhbiBpZ25vcmFudCBxdWVzdGlvbi4NCj4gPg0KPiA+IFRoZSBjb21taXQgbXNnIG9mIHBhdGNo
	NiBzYXlzIHRoYXQgVkZJTyBkb2Vzbid0IHRvbGVyYXRlIHVuYm91bmRlZA0KPiA+IHdhaXQsIHdo
	aWNoIGlzIHRoZSByZWFzb24gYmVoaW5kIHRoZSAybmQgdGltZW91dCB3YWl0IGhlcmUuDQo+IA0K
	PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGRtYWJ1ZiBkZXNpZ24gYSBmZW5jZSB3YWl0IHNob3Vs
	ZCBjb21wbGV0ZQ0KPiBldmVudHVhbGx5IHVuZGVyIGtlcm5lbCBjb250cm9sLCBiZWNhdXNlIHRo
	ZXNlIHNsZWVwcyBhcmUNCj4gc3ByaW5rbGVkIGFsbCBhcm91bmQgdGhlIGtlcm5lbCB0b2RheS4N
	Cj4gDQo+IEkgc3VzcGVjdCB0aGF0IGlzIG5vdCBhY3R1YWxseSB0cnVlIGZvciBldmVyeSBIVywg
	cHJvYmFibHkgc29tZXRoaW5nDQo+IGxpa2UgInNoYWRlciBwcm9ncmFtcyBjYW4gcnVuIGZvcmV2
	ZXIgdGVjaG5pY2FsbHkiLg0KPiANCj4gV2UgY2FuIGFyZ3VlIGlmIHRob3NlIGNhc2VzIHNob3Vs
	ZCBub3QgcmVwb3J0IHJldm9jYWJsZSBlaXRoZXIsIGJ1dCBhdA0KPiBsZWFzdCB0aGlzIHdpbGwg
	d29yayAiY29ycmVjdGx5IiBldmVuIGlmIGl0IHRha2VzIGEgaHVnZSBhbW91bnQgb2YNCj4gdGlt
	ZS4NCg0KZ29vZCB0byBrbm93IHRob3NlIGJhY2tncm91bmQuDQoNCj4gDQo+IEkgd291bGRuJ3Qg
	bWluZCBzZWVpbmcgYSBzaG9ydGVyIHRpbWVvdXQgYW5kIHByaW50IG9uIHRoZSBmZW5jZSB0b28N
	Cj4ganVzdCBpbiBjYXNlLg0KPiANCg0KZWl0aGVyIHdheSBpcyBPSy4gSXQncyBub3QgZGlmZmlj
	dWx0IHRvIGZpZ3VyZSBvdXQgYSBsb25nIHdhaXQgYW55d2F5LiDwn5iKDQo=

which is something that patch tools - in special patchwork - won't handle.

Thanks,
Mauro