From: sashiko-bot@kernel.org
To: "Guangshuo Li" <lgs201920130244@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI: keystone: fix endpoint teardown on remove
Date: Mon, 21 Sep 2026 14:35:13 +0000 [thread overview]
Message-ID: <20260921143514.4C7431F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921142147.435953-1-lgs201920130244@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: TOCTOU race in dw_pcie_ep_deinit() causing duplicate EPC deinit
--
commit e6751d7bce3085ac260a82fa5b3a315cc5808621
Author: Guangshuo Li <lgs201920130244@gmail.com>
PCI: keystone: fix endpoint teardown on remove
This commit fixes missing endpoint teardown in the keystone PCIe driver's
remove path. It makes dw_pcie_ep_deinit() notify the endpoint framework of
deinitialization directly, avoiding duplicated notification code in
controller drivers. It also caches the controller mode in struct
keystone_pcie to simplify teardown.
[ ... ]
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index de8ee3db43601..b785e098f7597 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -1188,6 +1188,9 @@ void dw_pcie_ep_deinit(struct dw_pcie_ep *ep)
> {
> struct pci_epc *epc = ep->epc;
>
> + if (epc->init_complete)
> + pci_epc_deinit_notify(epc);
> +
[Severity: High]
Can this unprotected check of epc->init_complete cause a TOCTOU race leading
to a double-free?
If the endpoint controller remove function calls dw_pcie_ep_deinit()
concurrently with a hardware interrupt like PERST calling
pci_epc_deinit_notify() directly, both threads could read
epc->init_complete as true without holding epc->list_lock.
Since pci_epc_deinit_notify() doesn't verify epc->init_complete under a
lock:
drivers/pci/endpoint/pci-epc-core.c:pci_epc_deinit_notify() {
...
mutex_unlock(&epf->lock);
}
epc->init_complete = false;
mutex_unlock(&epc->list_lock);
}
Could this result in duplicate calls to pci_epc_deinit_notify(), causing
EPF drivers like pci-epf-mhi to execute their epc_deinit callback twice
and double-free resources such as workqueues and caches?
> dw_pcie_ep_cleanup(ep);
>
> pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260921142147.435953-1-lgs201920130244@gmail.com?part=1
prev parent reply other threads:[~2026-09-21 14:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 14:21 [PATCH v2] PCI: keystone: fix endpoint teardown on remove Guangshuo Li
2026-09-21 14:35 ` sashiko-bot [this message]
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=20260921143514.4C7431F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=lgs201920130244@gmail.com \
--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.