From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: linux-pci@vger.kernel.org, ntb@lists.linux.dev
Subject: Re: [PATCH v8 02/10] PCI: dwc: Expose endpoint DMA resources
Date: Thu, 22 Oct 2026 08:42:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-181198@kernel.org> (raw)
In-Reply-To: <20261022082230.3164834-3-den@valinux.co.jp>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] PCI: dwc: stale edma->dw in dw_pcie_ep_get_aux_resources() after eDMA removal
--
commit 9475ea2f70e5c9c7b09a2bc537c0f97a6e428f7f
Author: Koichiro Den <den@valinux.co.jp>
PCI: dwc: Expose endpoint DMA resources
This commit exposes the endpoint-integrated eDMA register window and
linked-list memory regions via the EPC auxiliary resource API. It also
checks that the local dw-edma device is registered and rejects virtual
function queries.
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 630ba172280c2..7166ec7f212bd 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
[ ... ]
> @@ -865,14 +874,30 @@ dw_pcie_ep_get_aux_resources_count(struct pci_epc *epc, u8 func_no,
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct dw_edma_chip *edma = &pci->edma;
> + u16 ll_wr_cnt, ll_rd_cnt;
> + int count = 0;
> + int ret;
>
> if (!pci->edma_reg_size)
> return 0;
>
> - if (edma->db_offset == ~0)
> + ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
> + if (ret)
> + return ret;
> +
> + if (!edma->dw)
> return 0;
>
> - return 1;
> + ll_wr_cnt = edma->ll_wr_cnt;
> + ll_rd_cnt = edma->ll_rd_cnt;
> +
> + if (!edma->cfg_non_ll)
> + count += 1 + ll_wr_cnt + ll_rd_cnt;
> +
> + if (edma->db_offset != ~0)
> + count++;
> +
> + return count;
> }
>
> static int
> @@ -885,14 +910,32 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> const struct pci_epc_bar_rsvd_region *rsvd;
> struct dw_edma_chip *edma = &pci->edma;
> enum pci_barno dma_ctrl_bar = NO_BAR;
> - resource_size_t db_offset = edma->db_offset;
> + resource_size_t db_offset;
> resource_size_t dma_ctrl_bar_offset = 0;
> resource_size_t dma_reg_size;
> - int count;
> + u16 ll_wr_cnt, ll_rd_cnt;
> + bool has_ll;
> + unsigned int i;
> + int count, ret;
>
> - count = dw_pcie_ep_get_aux_resources_count(epc, func_no, vfunc_no);
> - if (count < 0)
> - return count;
> + if (!pci->edma_reg_size)
> + return 0;
> +
> + ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
> + if (ret)
> + return ret;
> +
> + if (!edma->dw)
> + return 0;
> +
> + ll_wr_cnt = edma->ll_wr_cnt;
> + ll_rd_cnt = edma->ll_rd_cnt;
> + db_offset = edma->db_offset;
> + has_ll = !edma->cfg_non_ll;
> +
> + count = db_offset != ~0;
> + if (has_ll)
> + count += 1 + ll_wr_cnt + ll_rd_cnt;
[Severity: Medium]
Can edma->dw remain a non-NULL stale pointer here after the local dw-edma
device has been unregistered?
Both dw_pcie_ep_get_aux_resources_count() and dw_pcie_ep_get_aux_resources()
check edma->dw to verify that the local dw-edma device is registered before
exposing PCI_EPC_AUX_DMA_CTRL_MMIO and PCI_EPC_AUX_DMA_DESC_MEM resources.
However, when the eDMA device is torn down via dw_pcie_edma_remove() ->
dw_edma_remove(), either on the err_remove_edma error path in
dw_pcie_ep_init_registers():
drivers/pci/controller/dwc/pcie-designware-ep.c:dw_pcie_ep_init_registers() {
...
err_remove_edma:
dw_pcie_edma_remove(pci);
return ret;
}
or during fundamental reset in dw_pcie_ep_cleanup():
drivers/pci/controller/dwc/pcie-designware-ep.c:dw_pcie_ep_cleanup() {
...
dwc_pcie_debugfs_deinit(pci);
dw_pcie_edma_remove(pci);
}
dw_edma_remove() in drivers/dma/dw-edma/dw-edma-core.c unregisters the DMA
device (and resets chip->db_offset = ~0 via dw_edma_emul_irq_free()), but
neither dw_edma_remove() nor dw_pcie_edma_remove() clears chip->dw:
drivers/dma/dw-edma/dw-edma-core.c:dw_edma_remove() {
...
/* Deregister eDMA device */
dma_async_device_unregister(&dw->dma);
list_for_each_entry_safe(chan, _chan, &dw->dma.channels,
vc.chan.device_node) {
tasklet_kill(&chan->vc.task);
list_del(&chan->vc.chan.device_node);
}
return err;
}
If an endpoint function driver subsequently queries
pci_epc_get_aux_resources_count() and pci_epc_get_aux_resources() while the
eDMA device is unregistered, wouldn't the !edma->dw check pass and expose
DMA control MMIO and linked-list descriptor resources for a removed eDMA
instance?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261022082230.3164834-1-den@valinux.co.jp?part=2
next prev parent reply other threads:[~2026-10-22 8:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 8:22 [PATCH v8 00/10] PCI: endpoint: Remote DMA support via vNTB Koichiro Den
2026-10-22 8:22 ` [PATCH v8 01/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
2026-10-22 8:26 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 02/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
2026-10-22 8:42 ` sashiko-bot [this message]
2026-10-22 8:22 ` [PATCH v8 03/10] PCI: endpoint: pci-epf-vntb: Move epf_ntb_is_bar_used() up Koichiro Den
2026-10-22 8:25 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 04/10] PCI: endpoint: Add pci-epf-ntb.h for the shared NTB control layout Koichiro Den
2026-10-22 8:26 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 05/10] PCI: endpoint: pci-epf-vntb: Export endpoint DMA channels Koichiro Den
2026-10-22 8:53 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 06/10] PCI: endpoint: pci-epf-vntb: Allow DMA and MW to share a BAR Koichiro Den
2026-10-22 8:50 ` sashiko-bot
2026-10-22 15:41 ` Frank Li
2026-10-22 8:22 ` [PATCH v8 07/10] Documentation: PCI: endpoint: Document vNTB DMA export Koichiro Den
2026-10-22 8:27 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 08/10] NTB: ntb_hw_epf: Use the shared NTB control layout Koichiro Den
2026-10-22 8:30 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 09/10] NTB: ntb_hw_epf: Discover vNTB-embedded DMA Koichiro Den
2026-10-22 8:44 ` sashiko-bot
2026-10-22 8:22 ` [PATCH v8 10/10] NTB: ntb_hw_epf: Support DMA and MW sharing a BAR Koichiro Den
2026-10-22 8:34 ` sashiko-bot
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=sashiko-outbox-181198@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=den@valinux.co.jp \
--cc=linux-pci@vger.kernel.org \
--cc=ntb@lists.linux.dev \
--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.