From: Samiullah Khawaja <skhawaja@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-pci@vger.kernel.org,
Adithya Jayachandran <ajayachandra@nvidia.com>,
Alexander Graf <graf@amazon.com>,
Alex Williamson <alex@shazbot.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Chris Li <chrisl@kernel.org>,
David Rientjes <rientjes@google.com>,
Jacob Pan <jacob.pan@linux.microsoft.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Jonathan Corbet <corbet@lwn.net>,
Josh Hilke <jrhilke@google.com>,
Leon Romanovsky <leonro@nvidia.com>,
Lukas Wunner <lukas@wunner.de>, Mike Rapoport <rppt@kernel.org>,
Parav Pandit <parav@nvidia.com>,
Pranjal Shrivastava <praan@google.com>,
Pratyush Yadav <pratyush@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Shuah Khan <skhan@linuxfoundation.org>,
Vipin Sharma <vipinsh@google.com>, William Tu <witu@nvidia.com>,
Yi Liu <yi.l.liu@intel.com>
Subject: Re: [PATCH v7 03/12] PCI: liveupdate: Track incoming preserved PCI devices
Date: Tue, 21 Jul 2026 23:02:52 +0000 [thread overview]
Message-ID: <al_3nOssZoa6RoCq@google.com> (raw)
In-Reply-To: <CALzav=e1Gcu-9TD7F--41cYqKBrStKOE4VqQ4K3PKdNuYnNmcQ@mail.gmail.com>
On Mon, Jul 20, 2026 at 02:54:51PM -0700, David Matlack wrote:
>On Fri, Jul 17, 2026 at 2:47 PM Pasha Tatashin
><pasha.tatashin@soleen.com> wrote:
>>
>> On Fri, 10 Jul 2026 21:26:06 +0000, David Matlack <dmatlack@google.com> wrote:
>> > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
>> > index 03075ce06ac9..df6a02240aa4 100644
>> > --- a/drivers/pci/liveupdate.c
>> > +++ b/drivers/pci/liveupdate.c
>> > @@ -298,6 +377,87 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
>> > [ ... skip 76 lines ... ]
>> > + /*
>> > + * Hold the ref on the incoming FLB until pci_liveupdate_finish() so
>> > + * that dev->liveupdate.incoming cannot get freed while the PCI core
>> > + * has a pointer to it. It's better to leak the incoming FLB than do a
>> > + * use-after-free if driver does not call pci_liveupdate_finish().
>> > + */
>>
>> I am confused by this. Each preserved PCI device must have an associated
>> FD preserved with it via LUO. I.e., vfiofd would need to be preserved. If
>> the vfiofd was not reclaimed, and finish is not possible, that vfiofd
>> would still be owned by LUO, and therefore PCI FLB refcount would stay
>> positive.
>>
>> However, if finish is possible, and this is the last vfiofd that is
>> finished, FLB will be freed as soon as the reference count reaches zero,
>> which I would think is the expected behavior.
>>
>> What is the point of holding a reference here, instead of only for the
>> duration of FLB access, i.e. to make sure we are accessing a valid data?
>
>The duration of the access is from here until pci_liveupdate_finish()
>because that it when the pointer (dev->liveupdate.incoming) is
>cleared. So that is why the PCI core holds the reference from here
>until pci_liveupdate_finish().
I think LUO gives you guarantee that this pointer remains valid until
the FLB finish(), because all the vfiofd that were preserved have not
finished. And when all vfiofd have finished, LUO lets you know that the
pointer is becoming invalid so you can unset these in the finish()
callback from LUO?
If I understand this correctly, I think by keeping long references until
finish you are replicating the vfiofd bound lifecycle that LUO already
gives you.
>
>We could avoid this by deleteing dev->liveupdate.incoming and,
>instead, fetching the incoming FLB and doing the xarray lookup every
>atime the PCI core needs to access the device's incoming ser struct,
>but that would be inefficient.
Sami
next prev parent reply other threads:[~2026-07-21 23:02 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 21:26 [PATCH v7 00/12] PCI: liveupdate: PCI core support for Live Update David Matlack
2026-07-10 21:26 ` [PATCH v7 01/12] PCI: liveupdate: Set up FLB handler for the PCI core David Matlack
2026-07-10 21:36 ` sashiko-bot
2026-07-17 19:28 ` Pasha Tatashin
2026-07-17 19:30 ` Jason Gunthorpe
2026-07-17 19:40 ` Pasha Tatashin
2026-07-17 19:42 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 02/12] PCI: liveupdate: Track outgoing preserved PCI devices David Matlack
2026-07-10 21:39 ` sashiko-bot
2026-07-10 22:20 ` David Matlack
2026-07-17 19:38 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 03/12] PCI: liveupdate: Track incoming " David Matlack
2026-07-10 21:39 ` sashiko-bot
2026-07-10 22:31 ` David Matlack
2026-07-17 21:46 ` Pasha Tatashin
2026-07-20 21:54 ` David Matlack
2026-07-20 22:44 ` Pasha Tatashin
2026-07-20 23:07 ` David Matlack
2026-07-21 17:55 ` Pasha Tatashin
2026-07-21 20:25 ` David Matlack
2026-07-21 21:35 ` Pasha Tatashin
2026-07-21 23:02 ` Samiullah Khawaja [this message]
2026-07-21 23:16 ` David Matlack
2026-07-21 23:18 ` David Matlack
2026-07-21 23:46 ` Pasha Tatashin
2026-07-17 22:38 ` Alex Williamson
2026-07-20 22:00 ` David Matlack
2026-07-10 21:26 ` [PATCH v7 04/12] PCI: liveupdate: Document driver binding responsibilities David Matlack
2026-07-10 21:28 ` sashiko-bot
2026-07-10 21:26 ` [PATCH v7 05/12] PCI: liveupdate: Keep bus numbers constant during Live Update David Matlack
2026-07-10 21:32 ` sashiko-bot
2026-07-17 21:48 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 06/12] PCI: liveupdate: Auto-preserve upstream bridges across " David Matlack
2026-07-10 21:33 ` sashiko-bot
2026-07-17 22:00 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 07/12] PCI: Refactor matching logic for pci_dev_acs_ops David Matlack
2026-07-10 21:34 ` sashiko-bot
2026-07-17 22:02 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices David Matlack
2026-07-10 21:34 ` sashiko-bot
2026-07-17 22:08 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 09/12] PCI: liveupdate: Inherit ARI Forwarding Enable on preserved bridges David Matlack
2026-07-10 21:37 ` sashiko-bot
2026-07-10 22:07 ` David Matlack
2026-07-17 23:29 ` Pasha Tatashin
2026-07-20 23:19 ` David Matlack
2026-07-21 18:17 ` Pasha Tatashin
2026-07-21 20:26 ` David Matlack
2026-07-10 21:26 ` [PATCH v7 10/12] PCI: liveupdate: Freeze preservation status during shutdown David Matlack
2026-07-10 21:35 ` sashiko-bot
2026-07-17 23:30 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 11/12] PCI: liveupdate: Do not disable bus mastering on preserved devices during kexec David Matlack
2026-07-10 21:38 ` sashiko-bot
2026-07-17 23:32 ` Pasha Tatashin
2026-07-10 21:26 ` [PATCH v7 12/12] Documentation: PCI: Add documentation for Live Update David Matlack
2026-07-10 21:37 ` sashiko-bot
2026-07-17 23:38 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=al_3nOssZoa6RoCq@google.com \
--to=skhawaja@google.com \
--cc=ajayachandra@nvidia.com \
--cc=alex@shazbot.org \
--cc=bhelgaas@google.com \
--cc=chrisl@kernel.org \
--cc=corbet@lwn.net \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=jacob.pan@linux.microsoft.com \
--cc=jgg@nvidia.com \
--cc=jrhilke@google.com \
--cc=kexec@lists.infradead.org \
--cc=leonro@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=parav@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=praan@google.com \
--cc=pratyush@kernel.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=saeedm@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=vipinsh@google.com \
--cc=witu@nvidia.com \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox