From: sashiko-bot@kernel.org
To: "Shameer Kolothum" <skolothumtho@nvidia.com>
Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v2 14/16] vfio/pci: Block device access during host recovery
Date: Tue, 29 Sep 2026 17:51:33 +0000 [thread overview]
Message-ID: <20260929175133.605B51F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260929173305.204856-15-skolothumtho@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] cleanup: vfio_pci_core_enable() mixes goto and scoped_guard()
--
commit 054f5c9b3c995b5b332595d9db5677b803d39ed9
Author: Shameer Kolothum <skolothumtho@nvidia.com>
vfio/pci: Block device access during host recovery
This patch extends error_detected() to block device access during host
recovery by draining existing SRCU readers. It also masks INTx, revokes
BAR mappings, and manages the host transaction state across device open
and close.
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index d6cc34240b250..2ec8022e4a692 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -617,6 +617,15 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
> u16 cmd;
> u8 msix_pos;
>
> + if (vdev->pci_recovery_supported) {
> + if (pci_dev_is_disconnected(pdev))
> + return -ENODEV;
> + scoped_guard(mutex, &vdev->access_lock) {
[Severity: Low]
Does this mix scope-based cleanup with goto-based error handling in the same
function?
The cleanup subsystem guidelines in include/linux/cleanup.h state that goto
and cleanup helpers like scoped_guard() should never be mixed in the same
function to prevent ownership confusion. For a given routine, the expectation
is to convert all resources that need a goto cleanup to scope-based cleanup,
or convert none of them.
Looking at vfio_pci_core_enable(), the function still relies heavily on
legacy goto cleanup labels (like out_disable_device: and out_power:) on its
error paths.
Should this function be fully converted to scope-based cleanup first, or
should this new lock acquisition continue using the traditional lock and
unlock pattern to match the rest of the function?
> + if (vdev->pci_recovery_host_active)
> + return -EBUSY;
> + }
> + }
> +
> if (!vdev->disable_idle_d3) {
> ret = pm_runtime_resume_and_get(&pdev->dev);
> if (ret < 0)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929173305.204856-1-skolothumtho@nvidia.com?part=14
next prev parent reply other threads:[~2026-09-29 17:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 17:32 [RFC PATCH v2 00/16] vfio/pci: Handle PCI error recovery and report state to userspace Shameer Kolothum
2026-09-29 17:32 ` [RFC PATCH v2 01/16] vfio/pci: Add a device access gate Shameer Kolothum
2026-09-29 17:48 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 02/16] vfio/pci: Gate config space access Shameer Kolothum
2026-09-29 17:52 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 03/16] vfio/pci: Buffer ROM reads before copying to userspace Shameer Kolothum
2026-09-29 17:49 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 04/16] vfio/pci: Gate BAR and ROM access Shameer Kolothum
2026-09-29 17:41 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 05/16] vfio/pci: Fail BAR faults while access is blocked Shameer Kolothum
2026-09-29 17:45 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 06/16] vfio/pci: Gate interrupt configuration Shameer Kolothum
2026-09-29 17:43 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 07/16] vfio/pci: Gate function reset and runtime power management Shameer Kolothum
2026-09-29 17:48 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 08/16] vfio/pci: Gate device information queries and DMA-BUF export Shameer Kolothum
2026-09-29 17:44 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 09/16] vfio/pci: Add PCI error recovery state Shameer Kolothum
2026-09-29 17:44 ` sashiko-bot
2026-09-29 17:32 ` [RFC PATCH v2 10/16] vfio/pci: Quiesce INTx while access is blocked Shameer Kolothum
2026-09-29 17:45 ` sashiko-bot
2026-09-29 17:33 ` [RFC PATCH v2 11/16] vfio/pci: Add INTx recovery start and finish helpers Shameer Kolothum
2026-09-29 17:44 ` sashiko-bot
2026-09-29 17:33 ` [RFC PATCH v2 12/16] vfio/pci: Restore device state from slot_reset() Shameer Kolothum
2026-09-29 17:50 ` sashiko-bot
2026-09-29 17:33 ` [RFC PATCH v2 13/16] vfio/pci: Complete recovery in resume() Shameer Kolothum
2026-09-29 17:51 ` sashiko-bot
2026-09-29 17:33 ` [RFC PATCH v2 14/16] vfio/pci: Block device access during host recovery Shameer Kolothum
2026-09-29 17:51 ` sashiko-bot [this message]
2026-09-29 17:33 ` [RFC PATCH v2 15/16] vfio/pci: Add VFIO_DEVICE_FEATURE_PCI_ERROR_RECOVERY Shameer Kolothum
2026-09-29 17:48 ` sashiko-bot
2026-09-29 17:33 ` [RFC PATCH v2 16/16] vfio/pci: Enable host PCI error recovery for vfio-pci Shameer Kolothum
2026-09-29 17:49 ` sashiko-bot
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=20260929175133.605B51F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skolothumtho@nvidia.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