From: "Ionut Nechita (Wind River)" <ionut.nechita@windriver.com>
To: linux-pci@vger.kernel.org, bhelgaas@google.com
Cc: helgaas@kernel.org, sebott@linux.ibm.com, schnelle@linux.ibm.com,
bblock@linux.ibm.com, alifm@linux.ibm.com, julianr@linux.ibm.com,
dtatulea@nvidia.com, mani@kernel.org, ionut_n2001@yahoo.com,
sunlightlinux@gmail.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
"Ionut Nechita (Wind River)" <ionut.nechita@windriver.com>
Subject: [PATCH v5 0/1] PCI/IOV: Add reentrant locking in sriov_add_vfs/sriov_del_vfs
Date: Tue, 3 Mar 2026 10:09:01 +0200 [thread overview]
Message-ID: <20260303080903.28693-1-ionut.nechita@windriver.com> (raw)
Hi Bjorn,
This is v5 of the fix for the SR-IOV race between driver .remove()
and concurrent hotplug events (particularly on s390).
Changes since v4 (Feb 28):
- Replaced local pci_rescan_remove_owner variable with
mutex_get_owner() to check lock ownership, as suggested by
Manivannan Sadhasivam and agreed by Benjamin Block
- Removed owner tracking from pci_lock_rescan_remove() and
pci_unlock_rescan_remove() - they are now unchanged from upstream
- Rebased on linux-next (20260302)
Changes since v3 (Feb 25):
- Rebased on linux-next (next-20260227)
- Declared pci_rescan_remove_owner as const pointer
(const struct task_struct *) to make clear it is not meant to
modify the task (Benjamin Block)
- Added Reviewed-by and Tested-by from Benjamin Block (IBM)
Changes since v2 (Feb 19):
- Rebased on linux-next (next-20260225)
- Added Tested-by from Dragos Tatulea (NVIDIA)
- No code changes from v2
Changes since v1 (Feb 14):
- Renamed from pci_lock_rescan_remove_nested() to
pci_lock_rescan_remove_reentrant() to avoid confusion with
mutex_lock_nested() lockdep annotations (Benjamin Block)
- Added pci_unlock_rescan_remove_reentrant(const bool locked) helper
to avoid open-coding conditional unlock at each call site
(Benjamin Block)
- Moved declarations from drivers/pci/pci.h to include/linux/pci.h
alongside existing lock/unlock declarations (Benjamin Block)
- Simplified callers: removed negation of return value and manual
conditional unlock in favor of the paired lock/unlock helpers
The problem: on s390, platform-generated hot-unplug events for VFs
can race with sriov_del_vfs() when a PF driver is being unloaded.
The platform event handler takes pci_rescan_remove_lock, but
sriov_del_vfs() does not, leading to double removal and list
corruption. We cannot use a plain mutex_lock() because
sriov_del_vfs() may be called from paths that already hold the
lock (deadlock), and mutex_trylock() cannot distinguish self from
other holders.
The fix introduces pci_lock_rescan_remove_reentrant() which uses
mutex_get_owner() to check if the current task already holds the
lock, avoiding both deadlock and the trylock problem.
Link: https://lore.kernel.org/linux-pci/20260214193235.262219-3-ionut.nechita@windriver.com/ [v1]
Link: https://lore.kernel.org/linux-pci/20260219212648.82606-1-ionut.nechita@windriver.com/ [v2]
Link: https://lore.kernel.org/linux-pci/20260225202434.18737-1-ionut.nechita@windriver.com/ [v3]
Link: https://lore.kernel.org/linux-pci/20260228120138.51197-2-ionut.nechita@windriver.com/ [v4]
Ionut Nechita (1):
PCI/IOV: Add reentrant locking in sriov_add_vfs/sriov_del_vfs for
complete serialization
drivers/pci/iov.c | 7 +++++++
drivers/pci/probe.c | 16 ++++++++++++++++
include/linux/pci.h | 2 ++
3 files changed, 25 insertions(+)
--
2.53.0
next reply other threads:[~2026-03-03 8:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 8:09 Ionut Nechita (Wind River) [this message]
2026-03-03 8:09 ` [PATCH v5 1/1] PCI/IOV: Add reentrant locking in sriov_add_vfs/sriov_del_vfs for complete serialization Ionut Nechita (Wind River)
2026-03-03 18:19 ` Lukas Wunner
2026-03-03 19:28 ` Lukas Wunner
2026-03-03 19:56 ` Niklas Schnelle
2026-03-03 20:02 ` Keith Busch
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=20260303080903.28693-1-ionut.nechita@windriver.com \
--to=ionut.nechita@windriver.com \
--cc=alifm@linux.ibm.com \
--cc=bblock@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=dtatulea@nvidia.com \
--cc=helgaas@kernel.org \
--cc=ionut_n2001@yahoo.com \
--cc=julianr@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=sebott@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=sunlightlinux@gmail.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
all inboxes | Powered by JetHome®