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: <2d9339db-4d26-4ff7-8390-5ac5c0a92401@amd.com>
Date: Fri, 30 Jan 2026 09:46:55 +0100
From: Christian König <christian.koenig@....com>
To: Jason Gunthorpe <jgg@...pe.ca>, "Tian, Kevin" <kevin.tian@...el.com>
Cc: Leon Romanovsky <leon@...nel.org>, Pranjal Shrivastava
 <praan@...gle.com>, Sumit Semwal <sumit.semwal@...aro.org>,
 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 1/29/26 15:58, Jason Gunthorpe wrote:
> 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.

Well it's a bit different, but we indeed guarantee that dma_fences complete in finite time.

> I suspect that is not actually true for every HW, probably something
> like "shader programs can run forever technically".

Nope, stuff like that is strictly forbidden.

Regards,
Christian.

> 
> 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.
> 
> I wouldn't mind seeing a shorter timeout and print on the fence too
> just in case.
> 
> Jason


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ