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: <d1dce6c1-9a89-4ae4-90eb-7b6d8cdcdd91@amd.com>
Date: Fri, 30 Jan 2026 15:11:48 +0100
From: Christian König <christian.koenig@....com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Leon Romanovsky <leon@...nel.org>, 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>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Kevin Tian <kevin.tian@...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>,
 Vivek Kasireddy <vivek.kasireddy@...el.com>, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
 virtualization@...ts.linux.dev, intel-xe@...ts.freedesktop.org,
 linux-rdma@...r.kernel.org, iommu@...ts.linux.dev, kvm@...r.kernel.org
Subject: Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete

On 1/30/26 14:56, Jason Gunthorpe wrote:
> On Fri, Jan 30, 2026 at 02:21:08PM +0100, Christian König wrote:
> 
>> That would work for me.
>>
>> Question is if you really want to do it this way? See usually
>> exporters try to avoid blocking such functions.
> 
> Yes, it has to be this way, revoke is a synchronous user space
> triggered operation around things like FLR or device close. We can't
> defer it into some background operation like pm.

Yeah, but you only need that in a couple of use cases and not all.

Especially when the device is idle exporters usually don't want runtime PM to kick in and try to suspend the device while importers are still using it.

> 
>>>>>  		}
>>>>>  		fput(priv->dmabuf->file);
>>>>
>>>> This is also extremely questionable. Why doesn't the dmabuf have
>>>> a reference while on the linked list?
> 
> If we hold a refcount while on the list then the FD can never be
> closed.
> 
> There is locking protecting the list so that it is safe and close
> continues to work right.

Ah! You use get_file_active(), yeah that should work.

Thanks,
Christian.


> 
> Jason