From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: ntb@lists.linux.dev, linux-pci@vger.kernel.org
Subject: Re: [PATCH 08/11] NTB: perf: Reject grouped memory windows
Date: Mon, 03 Aug 2026 18:25:21 +0000 [thread overview]
Message-ID: <20260803182521.EDE151F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260803180439.1963864-9-den@valinux.co.jp>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Mismatch in memory window indices (`perf->gidx` vs `peer->gidx`) breaks test communication on multi-port configurations.
- [High] Multiple test threads executing concurrently map memory and overwrite a shared `peer->dma_dst_addr`, leading to DMA mapping leaks, IOMMU faults, and double-unmapping.
--
--- Patch [8]: [PATCH 08/11] NTB: perf: Reject grouped memory windows ---
commit 8a37bed871c2fb90c1fc72578c46b05070e8ad53
Author: Koichiro Den <den@valinux.co.jp>
NTB: perf: Reject grouped memory windows
NTB perf configures one MW per peer through the per-MW translation API.
It cannot configure one member of a larger translation group.
Reject such layouts at probe.
> diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
> index dfd175f79e8f0..50bfbec1e251e 100644
> --- a/drivers/ntb/test/ntb_perf.c
> +++ b/drivers/ntb/test/ntb_perf.c
[ ... ]
> @@ -1469,7 +1469,19 @@ static int perf_init_peers(struct perf_ctx *perf)
> }
>
> for (pidx = 0; pidx < perf->pcnt; pidx++) {
> - ret = perf_setup_peer_mw(&perf->peers[pidx]);
> + peer = &perf->peers[pidx];
> + ret = ntb_mw_get_trans_group(perf->ntb, peer->pidx,
> + peer->gidx, &first, &count);
> + if (ret)
> + return ret;
> + if (first != peer->gidx || count != 1) {
> + dev_err(&perf->ntb->dev,
> + "Peer %d MW %d is not a standalone window\n",
> + peer->pidx, peer->gidx);
> + return -EOPNOTSUPP;
> + }
> +
> + ret = perf_setup_peer_mw(peer);
[Severity: High]
This is a pre-existing issue, but does perf_setup_peer_mw() incorrectly mix
index variables on multi-port configurations?
Looking at perf_setup_peer_mw(), it maps the physical address of the
outbound window using the local port's index (perf->gidx):
ret = ntb_peer_mw_get_addr(perf->ntb, perf->gidx, &phys_addr,
&peer->outbuf_size);
However, perf_setup_outbuf() later configures the outbound translation using
the peer's index (peer->gidx):
ret = ntb_peer_mw_set_trans(perf->ntb, peer->pidx, peer->gidx,
peer->outbuf_xlat, peer->outbuf_size);
When perf->gidx and peer->gidx differ, this mismatch causes writes to the
mapped memory to go to an unconfigured window.
The same index mismatch occurs for inbound windows between ntb_mw_get_align()
and ntb_mw_set_trans().
Could we use a consistent index?
[Severity: High]
This is a pre-existing issue, but can multiple concurrent test threads
overwrite peer->dma_dst_addr and leak DMA allocations?
When a user configures multiple test threads, they all execute
perf_init_test() concurrently without serialization.
Because they share the same perf->test_peer structure, they each call
dma_map_resource() and overwrite peer->dma_dst_addr:
drivers/ntb/test/ntb_perf.c:perf_init_test() {
...
peer->dma_dst_addr =
dma_map_resource(pthr->dma_chan->device->dev,
peer->out_phys_addr, peer->outbuf_size,
DMA_FROM_DEVICE, 0);
...
}
Later, threads may read an IOVA mapped for a completely different DMA device
in perf_copy_chunk():
dst_dma_addr = peer->dma_dst_addr + (dst_vaddr - vbase);
During teardown, all threads call dma_unmap_resource() on the exact same
pointer in perf_clear_test(), causing a double-unmap:
dma_unmap_resource(pthr->dma_chan->device->dev,
pthr->perf->test_peer->dma_dst_addr,
pthr->perf->test_peer->outbuf_size,
DMA_FROM_DEVICE, 0);
Does this sequence need additional locking or per-thread DMA mapping tracking?
> if (ret)
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803180439.1963864-1-den@valinux.co.jp?part=8
next prev parent reply other threads:[~2026-08-03 18:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 18:04 [PATCH 00/11] PCI/NTB: endpoint: packed vNTB memory windows Koichiro Den
2026-08-03 18:04 ` [PATCH 01/11] NTB: Add atomic MW translation group operations Koichiro Den
2026-08-03 18:10 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 02/11] NTB: epf: Parse a versioned packed MW layout Koichiro Den
2026-08-03 18:23 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 03/11] PCI: endpoint: pci-epf-vntb: Add packed MW layout handling Koichiro Den
2026-08-03 18:25 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 04/11] PCI: endpoint: pci-epf-vntb: Implement MW group translation callbacks Koichiro Den
2026-08-03 18:25 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 05/11] PCI: endpoint: pci-epf-vntb: Allocate packed outbound MW space Koichiro Den
2026-08-03 18:32 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 06/11] PCI: endpoint: pci-epf-vntb: Add outbound MW group commands Koichiro Den
2026-08-03 18:28 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 07/11] NTB: epf: Implement MW group translation callbacks Koichiro Den
2026-08-03 18:29 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 08/11] NTB: perf: Reject grouped memory windows Koichiro Den
2026-08-03 18:25 ` sashiko-bot [this message]
2026-08-03 18:04 ` [PATCH 09/11] NTB/msi: Require a singleton memory window Koichiro Den
2026-08-03 18:23 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 10/11] NTB: ntb_transport: Use atomic MW translation groups Koichiro Den
2026-08-03 18:40 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 11/11] PCI: endpoint: pci-epf-vntb: Expose packed MWs through configfs Koichiro Den
2026-08-03 18:40 ` sashiko-bot
2026-08-03 23:00 ` [PATCH 00/11] PCI/NTB: endpoint: packed vNTB memory windows Randy Dunlap
2026-08-04 0:55 ` Koichiro Den
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=20260803182521.EDE151F00A3A@smtp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox