mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Lukas Wunner <lukas@wunner.de>,
	"Ionut Nechita (Wind River)" <ionut.nechita@windriver.com>
Cc: linux-pci@vger.kernel.org, helgaas@kernel.org,
	sebott@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
Subject: Re: [PATCH v5 1/1] PCI/IOV: Add reentrant locking in sriov_add_vfs/sriov_del_vfs for complete serialization
Date: Tue, 03 Mar 2026 20:56:24 +0100	[thread overview]
Message-ID: <286d0488aa72b1741f93f900fd5db5c4334a6f50.camel@linux.ibm.com> (raw)
In-Reply-To: <aac2bUCCX3dZcwo0@wunner.de>

On Tue, 2026-03-03 at 20:28 +0100, Lukas Wunner wrote:
> On Tue, Mar 03, 2026 at 07:19:31PM +0100, Lukas Wunner wrote:
> > Also, I would put this in the existing pci_lock_rescan_remove(),
> > i.e. without introducing a new _reentrant variant, because these
> > deadlocks exist elsewhere.  They're known to happen on unplug in
> > pciehp as well.
> 
> Actually, scratch this particular comment.  The deadlock in pciehp
> is actually an AB-BA deadlock, not recursive acquisition.

Hi Lukas,

Do you have a link to a report or a lockdep splat for this issue? We're
currently working on another series restructuring the use of the
rescan/remove lock in s390 PCI code to handle another deadlock. And
while most of that is s390 specific code this may give helpful
insights. Also definitely underlines how tricky this lock is.

Thanks,
Niklas

  reply	other threads:[~2026-03-03 19:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03  8:09 [PATCH v5 0/1] PCI/IOV: Add reentrant locking in sriov_add_vfs/sriov_del_vfs Ionut Nechita (Wind River)
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 [this message]
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=286d0488aa72b1741f93f900fd5db5c4334a6f50.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=alifm@linux.ibm.com \
    --cc=bblock@linux.ibm.com \
    --cc=dtatulea@nvidia.com \
    --cc=helgaas@kernel.org \
    --cc=ionut.nechita@windriver.com \
    --cc=ionut_n2001@yahoo.com \
    --cc=julianr@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mani@kernel.org \
    --cc=sebott@linux.ibm.com \
    --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
Powered by JetHome