From: Timothy Pearson <tpearson@raptorengineering.com>
To: Narayana Murty N <nnmlinux@linux.ibm.com>
Cc: mahesh <mahesh@linux.ibm.com>, Oliver <oohall@gmail.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
npiggin <npiggin@gmail.com>,
christophe leroy <christophe.leroy@csgroup.eu>,
Bjorn Helgaas <bhelgaas@google.com>,
Timothy Pearson <tpearson@raptorengineering.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
vaibhav <vaibhav@linux.ibm.com>,
Shivaprasad G Bhat <sbhat@linux.ibm.com>,
ganeshgr@linux.ibm.com
Subject: Re: [PATCH v2 1/1] powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling
Date: Thu, 11 Dec 2025 09:45:44 -0600 (CST) [thread overview]
Message-ID: <1869613445.153778.1765467944808.JavaMail.zimbra@raptorengineeringinc.com> (raw)
In-Reply-To: <20251210142559.8874-1-nnmlinux@linux.ibm.com>
----- Original Message -----
> From: "Narayana Murty N" <nnmlinux@linux.ibm.com>
> To: "mahesh" <mahesh@linux.ibm.com>, "Oliver" <oohall@gmail.com>, "Madhavan Srinivasan" <maddy@linux.ibm.com>, "Michael
> Ellerman" <mpe@ellerman.id.au>, "npiggin" <npiggin@gmail.com>, "christophe leroy" <christophe.leroy@csgroup.eu>
> Cc: "Bjorn Helgaas" <bhelgaas@google.com>, "Timothy Pearson" <tpearson@raptorengineering.com>, "linuxppc-dev"
> <linuxppc-dev@lists.ozlabs.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "vaibhav" <vaibhav@linux.ibm.com>,
> "Shivaprasad G Bhat" <sbhat@linux.ibm.com>, ganeshgr@linux.ibm.com
> Sent: Wednesday, December 10, 2025 8:25:59 AM
> Subject: [PATCH v2 1/1] powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling
> The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device
> hotplug safe") restructured the EEH driver to improve synchronization
> with the PCI hotplug layer.
>
> However, it inadvertently moved pci_lock_rescan_remove() outside its
> intended scope in eeh_handle_normal_event(), leading to broken PCI
> error reporting and improper EEH event triggering. Specifically,
> eeh_handle_normal_event() acquired pci_lock_rescan_remove() before
> calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to
> acquire the same lock internally, causing nested locking and disrupting
> normal EEH event handling paths.
>
> This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(),
> with two public wrappers:
> eeh_pe_bus_get() with locking enabled.
> eeh_pe_bus_get_nolock() that skips locking.
>
> Callers that already hold pci_lock_rescan_remove() now use
> eeh_pe_bus_get_nolock() to avoid recursive lock acquisition.
>
> Additionally, pci_lock_rescan_remove() calls are restored to the correct
> position—after eeh_pe_bus_get() and immediately before iterating affected
> PEs and devices. This ensures EEH-triggered PCI removes occur under proper
> bus rescan locking without recursive lock contention.
>
> The eeh_pe_loc_get() function has been split into two functions:
> eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE.
> eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location
> code for given bus.
Conceptually the patch sounds OK, but given the complexity of these subsystems it's difficult to forsee all interactions. Was the patch verified not to break NVMe hotplug on PowerNV systems using actual hardware? If not, I will need to do so before sending an ack. Thanks!
next prev parent reply other threads:[~2025-12-11 15:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 14:25 Narayana Murty N
2025-12-10 21:46 ` Bjorn Helgaas
2025-12-15 6:35 ` Narayana Murty N
2025-12-11 15:45 ` Timothy Pearson [this message]
2025-12-17 5:01 ` Narayana Murty N
2025-12-22 5:35 ` Nilay Shroff
2026-01-05 9:47 ` Narayana Murty N
2026-01-07 6:22 ` Narayana Murty N
2026-01-14 3:04 ` Madhavan Srinivasan
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=1869613445.153778.1765467944808.JavaMail.zimbra@raptorengineeringinc.com \
--to=tpearson@raptorengineering.com \
--cc=bhelgaas@google.com \
--cc=christophe.leroy@csgroup.eu \
--cc=ganeshgr@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=nnmlinux@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.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®