linux-kernel - Re: [PATCH 00/21] vfio/pci: Base support to preserve a VFIO device file across Live Update

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: <86bjkhm0tp.fsf@kernel.org>
Date: Tue, 02 Dec 2025 15:10:26 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: David Matlack <dmatlack@...gle.com>,  Alex Williamson
 <alex@...zbot.org>,  Adithya Jayachandran <ajayachandra@...dia.com>,  Alex
 Mastro <amastro@...com>,  Alistair Popple <apopple@...dia.com>,  Andrew
 Morton <akpm@...ux-foundation.org>,  Bjorn Helgaas <bhelgaas@...gle.com>,
  Chris Li <chrisl@...nel.org>,  David Rientjes <rientjes@...gle.com>,
  Jacob Pan <jacob.pan@...ux.microsoft.com>,  Jason Gunthorpe
 <jgg@...dia.com>,  Jason Gunthorpe <jgg@...pe.ca>,  Josh Hilke
 <jrhilke@...gle.com>,  Kevin Tian <kevin.tian@...el.com>,
  kvm@...r.kernel.org,  Leon Romanovsky <leonro@...dia.com>,
  linux-kernel@...r.kernel.org,  linux-kselftest@...r.kernel.org,
  linux-pci@...r.kernel.org,  Lukas Wunner <lukas@...ner.de>,  Mike
 Rapoport <rppt@...nel.org>,  Parav Pandit <parav@...dia.com>,  Philipp
 Stanner <pstanner@...hat.com>,  Pratyush Yadav <pratyush@...nel.org>,
  Saeed Mahameed <saeedm@...dia.com>,  Samiullah Khawaja
 <skhawaja@...gle.com>,  Shuah Khan <shuah@...nel.org>,  Tomita Moeko
 <tomitamoeko@...il.com>,  Vipin Sharma <vipinsh@...gle.com>,  William Tu
 <witu@...dia.com>,  Yi Liu <yi.l.liu@...el.com>,  Yunxiang Li
 <Yunxiang.Li@....com>,  Zhu Yanjun <yanjun.zhu@...ux.dev>
Subject: Re: [PATCH 00/21] vfio/pci: Base support to preserve a VFIO device
 file across Live Update

On Mon, Dec 01 2025, Pasha Tatashin wrote:

> On Wed, Nov 26, 2025 at 2:36 PM David Matlack <dmatlack@...gle.com> wrote:
[...]
>> FLB Locking
>>
>>   I don't see a way to properly synchronize pci_flb_finish() with
>>   pci_liveupdate_incoming_is_preserved() since the incoming FLB mutex is
>>   dropped by liveupdate_flb_get_incoming() when it returns the pointer
>>   to the object, and taking pci_flb_incoming_lock in pci_flb_finish()
>>   could result in a deadlock due to reversing the lock ordering.

My mental model for FLB is that it is a dependency for files, so it
should always be created (aka prepare) before _any_ of the files, and
always destroyed (aka finish) after _all_ of the files.

By the time the FLB is being finished, all the files for that FLB should
also be finished, so there should no longer be a user of the FLB.

Once all of the files are finished, it should be LUO's responsibility to
make sure liveupdate_flb_get_incoming() returns an error _before_ it
starts doing the FLB finish. And in FLB finish you should not be needing
to take any locks.

Why do you want to use the FLB when it is being finished?

>
> I will re-introduce _lock/_unlock API to solve this issue.
>
>>
>> FLB Retrieving
>>
>>   The first patch of this series includes a fix to prevent an FLB from
>>   being retrieved again it is finished. I am wondering if this is the
>>   right approach or if subsystems are expected to stop calling
>>   liveupdate_flb_get_incoming() after an FLB is finished.

IMO once the FLB is finished, LUO should make sure it cannot be
retrieved, mainly so subsystem code is simpler and less bug-prone.

>
> Thanks, I will include this fix in the next version of FLB.

-- 
Regards,
Pratyush Yadav