From: sashiko-bot@kernel.org
To: "Alex Williamson" <alex.williamson@nvidia.com>
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs
Date: Wed, 12 Aug 2026 05:01:01 +0000 [thread overview]
Message-ID: <20260812050102.350681F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812045325.2733631-2-alex.williamson@nvidia.com>
> pci_reset_function() and its locked and try variants are intended to
> provide a function-scoped reset. The bus and slot methods supporting
> this interface refuse when sibling or subordinate devices are present.
> SR-IOV VFs however, are not currently considered in this scope.
>
> Correct this oversight by testing for non-zero VF count in calls
> through the pci_reset_function() interfaces. This test needs to occur
> under device_lock to avoid races with .sriov_configure. It should
> also occur before pci_dev_save_and_disable() to avoid calling
> potentially destructive reset hooks. Tests are therefore added
> to each of pci_reset_function(), pci_reset_function_locked(), and
> pci_try_reset_function().
>
> The __pci_reset_function_locked() interface remains a low-level
> primitive depending on the caller to perform such tests as necessary.
> The vfio_pci_core use case of __pci_reset_function_locked() is pulled
> through with this test. Other use cases, such as xen-pciback, that
> don't obviously support or prevent binding to SR-IOV enabled PFs will
> need to decide whether VFs are possible and can be preserved.
> Additionally, direct callers of sriov_enable() that do not hold
> device_lock (lpfc) are considered a preexisting, non-compliance issue.
>
> Fixes: dd7cc44d0bce ("PCI: add SR-IOV API for Physical Function driver")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812045325.2733631-1-alex.williamson@nvidia.com?part=1
next prev parent reply other threads:[~2026-08-12 5:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 4:53 [RFC PATCH 0/5] PCI/vfio-pci: Guard resets against active SR-IOV VFs Alex Williamson
2026-08-12 4:53 ` [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs Alex Williamson
2026-08-12 5:01 ` sashiko-bot [this message]
2026-08-12 4:53 ` [RFC PATCH 2/5] PCI: Add pci_reset_bus_cond() for a caller-gated slot or bus reset Alex Williamson
2026-08-12 5:00 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 3/5] vfio/pci: Refuse to reset an SR-IOV PF with enabled VFs Alex Williamson
2026-08-12 5:02 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 4/5] PCI: Export pci_reset_supported() Alex Williamson
2026-08-12 4:59 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 5/5] vfio/pci: Use pci_reset_supported() in place of reset_works Alex Williamson
2026-08-12 4:59 ` 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=20260812050102.350681F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alex.williamson@nvidia.com \
--cc=kvm@vger.kernel.org \
--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.