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: <BN9PR11MB527617D8029B43B093B789D08C9FA@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 30 Jan 2026 05:48:51 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
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

> From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
> Sent: Friday, January 30, 2026 1:43 PM
> 
> 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

it's likely caused by the trailing smile icon. I'll pay attention to it.

> 
> Your message content is:
> 
> 	PiBGcm9tOiBKYXNvbiBHdW50aG9ycGUgPGpnZ0B6aWVwZS5jYT4NCj
> 4gU2VudDogVGh1cnNkYXks
> 	IEphbnVhcnkgMjksIDIwMjYgMTA6NTkgUE0NCj4gDQo+IE9uIFRodSw
> gSmFuIDI5LCAyMDI2IGF0
> 	IDA3OjA2OjM3QU0gKzAwMDAsIFRpYW4sIEtldmluIHdyb3RlOg0KPiA+
> IEJlYXIgbWUgaWYgaXQn
> 	cyBhbiBpZ25vcmFudCBxdWVzdGlvbi4NCj4gPg0KPiA+IFRoZSBjb21taX
> QgbXNnIG9mIHBhdGNo
> 	NiBzYXlzIHRoYXQgVkZJTyBkb2Vzbid0IHRvbGVyYXRlIHVuYm91bmRlZ
> A0KPiA+IHdhaXQsIHdo
> 	aWNoIGlzIHRoZSByZWFzb24gYmVoaW5kIHRoZSAybmQgdGltZW91dC
> B3YWl0IGhlcmUuDQo+IA0K
> 	PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGRtYWJ1ZiBkZXNpZ24gYSB
> mZW5jZSB3YWl0IHNob3Vs
> 	ZCBjb21wbGV0ZQ0KPiBldmVudHVhbGx5IHVuZGVyIGtlcm5lbCBjb250
> cm9sLCBiZWNhdXNlIHRo
> 	ZXNlIHNsZWVwcyBhcmUNCj4gc3ByaW5rbGVkIGFsbCBhcm91bmQgd
> GhlIGtlcm5lbCB0b2RheS4N
> 	Cj4gDQo+IEkgc3VzcGVjdCB0aGF0IGlzIG5vdCBhY3R1YWxseSB0cnVlIG
> ZvciBldmVyeSBIVywg
> 	cHJvYmFibHkgc29tZXRoaW5nDQo+IGxpa2UgInNoYWRlciBwcm9ncmF
> tcyBjYW4gcnVuIGZvcmV2
> 	ZXIgdGVjaG5pY2FsbHkiLg0KPiANCj4gV2UgY2FuIGFyZ3VlIGlmIHRob3
> NlIGNhc2VzIHNob3Vs
> 	ZCBub3QgcmVwb3J0IHJldm9jYWJsZSBlaXRoZXIsIGJ1dCBhdA0KPiBsZ
> WFzdCB0aGlzIHdpbGwg
> 	d29yayAiY29ycmVjdGx5IiBldmVuIGlmIGl0IHRha2VzIGEgaHVnZSBhbW
> 91bnQgb2YNCj4gdGlt
> 	ZS4NCg0KZ29vZCB0byBrbm93IHRob3NlIGJhY2tncm91bmQuDQoNCj4
> gDQo+IEkgd291bGRuJ3Qg
> 	bWluZCBzZWVpbmcgYSBzaG9ydGVyIHRpbWVvdXQgYW5kIHByaW50I
> G9uIHRoZSBmZW5jZSB0b28N
> 	Cj4ganVzdCBpbiBjYXNlLg0KPiANCg0KZWl0aGVyIHdheSBpcyBPSy4gSX
> QncyBub3QgZGlmZmlj
> 	dWx0IHRvIGZpZ3VyZSBvdXQgYSBsb25nIHdhaXQgYW55d2F5LiDwn5i
> KDQo=
> 
> which is something that patch tools - in special patchwork - won't handle.
> 
> Thanks,
> Mauro