linux-kernel - Re: [PATCH v3 6/7] 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: <98b74c7a-44c1-49ba-997b-bbbab60429ba@amd.com>
Date: Fri, 23 Jan 2026 17:23:34 +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 v3 6/7] vfio: Wait for dma-buf invalidation to complete

On 1/23/26 15:11, Jason Gunthorpe wrote:
> On Thu, Jan 22, 2026 at 07:44:04PM -0400, Jason Gunthorpe wrote:
>> On Thu, Jan 22, 2026 at 12:32:03PM +0100, Christian König wrote:
>>>>> What roughly happens is that each DMA-buf mapping through a couple
>>>>> of hoops keeps a reference on the device, so even after a hotplug
>>>>> event the device can only fully go away after all housekeeping
>>>>> structures are destroyed and buffers freed.
>>>>
>>>> A simple reference on the device means nothing for these kinds of
>>>> questions. It does not stop unloading and reloading a driver.
>>>
>>> Well as far as I know it stops the PCIe address space from being re-used.
>>>
>>> So when you do an "echo 1 > remove" and then an re-scan on the
>>> upstream bridge that works, but you get different addresses for your
>>> MMIO BARs!
>>
>> That's pretty a niche scenario.. Most people don't rescan their PCI
>> bus. If you just do rmmod/insmod then it will be re-used, there is no
>> rescan to move the MMIO around on that case.
> 
> Ah I just remembered there is another important detail here.
> 
> It is illegal to call the DMA API after your driver is unprobed. The
> kernel can oops. So if a driver is allowing remove() to complete
> before all the dma_buf_unmaps have been called it is buggy and risks
> an oops.
> 
> https://lore.kernel.org/lkml/8067f204-1380-4d37-8ffd-007fc6f26738@kernel.org/T/#m0c7dda0fb5981240879c5ca489176987d688844c
> 
> As calling a dma_buf_unmap() -> dma_unma_sg() after remove() returns
> is not allowed..

That is not even in the hands of the driver. The DMA-buf framework itself does a module_get() on the exporter.

So as long as a DMA-buf exists you *can't* rmmod the module which provides the exporting driver (expect of course of force unloading).

Revoking the DMA mappings won't change anything on that, the importer needs to stop using the DMA-buf and drop all their references.

Christian.

> 
> Jason