public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Keith Busch <kbusch@meta.com>,
	linux-pci@vger.kernel.org,  bhelgaas@google.com,
	alex@shazbot.org, Lukas Wunner <lukas@wunner.de>,
	 Keith Busch <kbusch@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	 Jinhui Guo <guojinhui.liam@bytedance.com>
Subject: Re: [PATCH 2/2] pci: fix slot reset device locking
Date: Wed, 28 Jan 2026 21:54:58 +0200 (EET)	[thread overview]
Message-ID: <aa3866ec-79d6-8eea-ca2c-8890a4c2b3bd@linux.intel.com> (raw)
In-Reply-To: <20260128180338.GA423654@bhelgaas>

On Wed, 28 Jan 2026, Bjorn Helgaas wrote:

> [+cc Dan, Jinhui]
> 
> On Fri, Jan 16, 2026 at 10:41:50AM -0800, Keith Busch wrote:
> > From: Keith Busch <kbusch@kernel.org>
> > 
> > Like pci_bus_lock, pci_slot_lock needs to lock the bridge device to
> > prevent the warning:
> 
> I *think* this actually refers to pci_bus_trylock() and
> pci_slot_trylock() (not pci_bus_lock() and pci_slot_lock()), since
> that's what this patch changes?
> 
> It's unfortunate that pci_bus_trylock() and pci_slot_trylock() are so
> similar but separate.  If there were combined, this kind of issue
> where one is fixed but the other isn't wouldn't happen.
> 
> But what about pci_bus_lock() and pci_slot_lock()?  They are also
> almost identical, but pci_bus_lock() locks bus->self while
> pci_slot_lock() does not.  Should it?
>
> All these almost-but-not-quite identical paths make my head hurt ;)

My series does attempt to consolidation them (check the pending patches 
from me).

(It doesn't consider this fix patch though but the other one is taken 
into account, the series was build on top of it).

-- 
 i.

> >   pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0
> > 
> > Signed-off-by: Keith Busch <kbusch@kernel.org>
> > ---
> >  drivers/pci/pci.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 3378221c5723a..5f8b0d06a1459 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -5460,6 +5460,8 @@ static void pci_slot_lock(struct pci_slot *slot)
> >  {
> >  	struct pci_dev *dev;
> >  
> > +	if (slot->bus->self)
> > +		pci_dev_lock(slot->bus->self);
> >  	list_for_each_entry(dev, &slot->bus->devices, bus_list) {
> >  		if (!dev->slot || dev->slot != slot)
> >  			continue;
> > @@ -5483,12 +5485,17 @@ static void pci_slot_unlock(struct pci_slot *slot)
> >  		else
> >  			pci_dev_unlock(dev);
> >  	}
> > +	if (slot->bus->self)
> > +		pci_dev_unlock(slot->bus->self);
> >  }
> >  
> >  /* Return 1 on successful lock, 0 on contention */
> >  static int pci_slot_trylock(struct pci_slot *slot)
> >  {
> > -	struct pci_dev *dev;
> > +	struct pci_dev *dev, *bridge = slot->bus->self;
> > +
> > +	if (bridge && !pci_dev_trylock(bridge))
> > +		return 0;
> >  
> >  	list_for_each_entry(dev, &slot->bus->devices, bus_list) {
> >  		if (!dev->slot || dev->slot != slot)
> > @@ -5511,6 +5518,9 @@ static int pci_slot_trylock(struct pci_slot *slot)
> >  		else
> >  			pci_dev_unlock(dev);
> >  	}
> > +
> > +	if (bridge)
> > +		pci_dev_unlock(bridge);
> >  	return 0;
> >  }
> >  
> > -- 
> > 2.47.3
> > 
> 


  parent reply	other threads:[~2026-01-28 19:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16 18:41 [PATCH 1/2] pci: fix slot trylock error handling Keith Busch
2026-01-16 18:41 ` [PATCH 2/2] pci: fix slot reset device locking Keith Busch
2026-01-28 18:03   ` Bjorn Helgaas
2026-01-28 19:13     ` Keith Busch
2026-01-28 22:53       ` Bjorn Helgaas
2026-01-29 15:59         ` Keith Busch
2026-01-28 19:54     ` Ilpo Järvinen [this message]
2026-01-28 21:07       ` dan.j.williams
2026-01-28 21:11         ` Bjorn Helgaas
2026-01-28 21:00   ` dan.j.williams
2026-01-27 16:09 ` [PATCH 1/2] pci: fix slot trylock error handling Keith Busch
2026-01-28  9:16   ` Ilpo Järvinen
2026-01-28 15:11     ` Keith Busch
2026-01-28 15:14       ` Ilpo Järvinen
2026-01-27 23:20 ` Bjorn Helgaas
2026-01-28 20:47 ` dan.j.williams

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=aa3866ec-79d6-8eea-ca2c-8890a4c2b3bd@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=guojinhui.liam@bytedance.com \
    --cc=helgaas@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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