From: sashiko-bot@kernel.org
To: "David Matlack" <dmatlack@google.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 06/11] PCI: liveupdate: Auto-preserve upstream bridges across Live Update
Date: Thu, 14 May 2026 02:05:17 +0000 [thread overview]
Message-ID: <20260514020517.DE0DFC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260512184846.119396-7-dmatlack@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Kernel stack overflow via deep recursion in `pci_liveupdate_preserve_path()`.
--
commit 9dcae64241d06ee18edeb26c25b9a7b263aa05a4
Author: David Matlack <dmatlack@google.com>
PCI: liveupdate: Auto-preserve upstream bridges across Live Update
This commit introduces tracking to auto-preserve upstream PCI bridges when a
device is preserved across a Live Update. It adds functions to preserve,
unpreserve, and finish the preservation of devices and recursively applies
these to upstream bridges up to the root port.
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> index 558fbaec8dddd..d8e06afde2c76 100644
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c
[ ... ]
> @@ -363,8 +389,82 @@ int pci_liveupdate_preserve(struct pci_dev *dev)
[ ... ]
> +static int pci_liveupdate_preserve_path(struct pci_ser *ser, struct pci_dev *dev)
> +{
> + int ret;
> +
> + if (!dev)
> + return 0;
> +
> + ret = pci_liveupdate_preserve_device(ser, dev);
> + if (ret)
> + return ret;
> +
> + ret = pci_liveupdate_preserve_path(ser, dev->bus->self);
Can this recursion cause a kernel stack overflow?
The PCI specification allows up to 256 nested buses in a single domain, which
can occur with deep Thunderbolt or USB4 topologies.
Because the recursive call to pci_liveupdate_preserve_path() is followed by a
potential call to pci_liveupdate_unpreserve_device(), it cannot be optimized
as a tail call. This forces a new stack frame for every level of the PCI
hierarchy, which could overflow the standard kernel stack, especially with
KASAN enabled, and cause a crash.
Could this be rewritten to use an iterative approach instead?
> + if (ret) {
> + pci_liveupdate_unpreserve_device(ser, dev);
> + return ret;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static void pci_liveupdate_unpreserve_path(struct pci_ser *ser, struct pci_dev *dev)
> +{
> + if (!dev)
> + return;
> +
> + if (pci_liveupdate_unpreserve_device(ser, dev))
> + return;
> +
> + pci_liveupdate_unpreserve_path(ser, dev->bus->self);
Does this code have the same recursion issue as pci_liveupdate_preserve_path()
and require an iterative approach?
> +}
[ ... ]
> @@ -519,28 +656,18 @@ void pci_liveupdate_cleanup_device(struct pci_dev *dev)
[ ... ]
> void pci_liveupdate_finish(struct pci_dev *dev)
> {
> - guard(write_lock)(&dev->liveupdate.lock);
> -
> - if (!dev->liveupdate.incoming) {
> - pci_warn(dev, "Cannot finish preserving an unpreserved device\n");
> + if (!dev)
> return;
> - }
> -
> - pci_info(dev, "Device is finished participating in Live Update\n");
>
> - /*
> - * Drop the refcount so this device does not get treated as an incoming
> - * device again, e.g. in case pci_liveupdate_setup_device() gets called
> - * again because the device is hot-plugged.
> - */
> - dev->liveupdate.incoming->refcount = 0;
> - dev->liveupdate.incoming = NULL;
> + if (pci_liveupdate_finish_device(dev))
> + return;
>
> - /* Drop this device's reference on the incoming FLB. */
> - pci_liveupdate_flb_put_incoming();
> + pci_liveupdate_finish(dev->bus->self);
Does this code also have the same recursion issue?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512184846.119396-1-dmatlack@google.com?part=6
next prev parent reply other threads:[~2026-05-14 2:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 18:48 [PATCH v5 00/11] PCI: liveupdate: PCI core support for Live Update David Matlack
2026-05-12 18:48 ` [PATCH v5 01/11] PCI: liveupdate: Set up FLB handler for the PCI core David Matlack
2026-05-12 18:48 ` [PATCH v5 02/11] PCI: liveupdate: Track outgoing preserved PCI devices David Matlack
2026-05-14 0:31 ` sashiko-bot
2026-05-14 18:16 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 03/11] PCI: liveupdate: Track incoming " David Matlack
2026-05-14 1:05 ` sashiko-bot
2026-05-14 18:27 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 04/11] PCI: liveupdate: Document driver binding responsibilities David Matlack
2026-05-12 18:48 ` [PATCH v5 05/11] PCI: liveupdate: Keep bus numbers constant during Live Update David Matlack
2026-05-14 1:36 ` sashiko-bot
2026-05-14 18:39 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 06/11] PCI: liveupdate: Auto-preserve upstream bridges across " David Matlack
2026-05-14 2:05 ` sashiko-bot [this message]
2026-05-14 18:41 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 07/11] PCI: liveupdate: Inherit ACS flags in incoming preserved devices David Matlack
2026-05-14 2:37 ` sashiko-bot
2026-05-14 18:46 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 08/11] PCI: liveupdate: Inherit ARI Forwarding Enable on preserved bridges David Matlack
2026-05-12 18:48 ` [PATCH v5 09/11] PCI: liveupdate: Freeze preservation status during shutdown David Matlack
2026-05-14 3:14 ` sashiko-bot
2026-05-14 18:48 ` David Matlack
2026-05-12 18:48 ` [PATCH v5 10/11] PCI: liveupdate: Do not disable bus mastering on preserved devices during kexec David Matlack
2026-05-12 18:48 ` [PATCH v5 11/11] Documentation: PCI: Add documentation for Live Update David Matlack
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=20260514020517.DE0DFC19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmatlack@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.