From: Stefan Metzmacher <metze@samba.org>
To: linux-rdma@vger.kernel.org
Cc: metze@samba.org, Tatyana Nikolova <tatyana.e.nikolova@intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Mustafa Ismail <mustafa.ismail@intel.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH] RDMA/irdma: always route IB_WR_REG_MR through the allocated PBL
Date: Wed, 7 Oct 2026 11:53:12 +0200 [thread overview]
Message-ID: <20261007095312.1523211-1-metze@samba.org> (raw)
irdma_alloc_mr() always allocates a PBL via irdma_get_pble(), but
irdma_post_send()'s IB_WR_REG_MR handling only pointed the FAST_REGISTER
WQE at that PBL (chunk_size != 0, first_pm_pbl_index) when
iwmr->npages exceeded IRDMA_MIN_PAGES_PER_FMR (1) - leaving chunk_size
at 0 for a single-page (npages == 1) registration, telling hardware to
use direct/PBL-less addressing for a registration that was never
allocated that way.
This reproduces as data corruption / an IOMMU IO_PAGE_FAULT when a
peer later performs an RDMA WRITE/READ against such a single-page
FRWR-registered MR, even though ib_map_mr_sg() itself reports success.
100% reproducible on iWARP, intermittent on RoCEv2, with fs/smb/smbdirect's
own single-page memory registrations on an Intel E810-CQDA2 (irdma).
Intel's current out-of-tree irdma driver (2.6.96) never gates this on
npages - it always sets chunk_size/first_pm_pbl_index based on the
actual PBL level (PBLE_LEVEL_1 vs PBLE_LEVEL_2), matching what
irdma_alloc_mr() actually allocated. Mirror that here instead of the
npages-based heuristic.
Also drop the reg_addr_pa assignment. irdma_sc_mr_fast_register()
packs reg_addr_pa into the FAST_REGISTER WQE's PBLADDR field, which
hardware only consults when chunk_size == 0 (direct/PBL-less
addressing); with chunk_size now always nonzero for this opcode, that
field is never read for IB_WR_REG_MR and the assignment is dead code -
Intel's driver never sets it for this path either (only the separate,
non-FRWR irdma_sc_mr_reg_non_shared() path actually branches on
chunk_size between reg_addr_pa and first_pm_pbl_index). Removing it is
not required for correctness: *palloc->level1.addr is always a
page-aligned address (low 12 bits zero), so it could never have
collided with the first_pm_pbl_index bits sharing those same bit
positions in the WQE word even if some path still read it.
This leaves one deliberate difference from irdma-2.6.96: that driver also
ties local_fence to the WR's IB_SEND_FENCE flag
(stag_info.local_fence = ib_wr->send_flags & IB_SEND_FENCE) rather than
hardcoding it true for IB_WR_REG_MR. That is a separate, non-corruption
behavioural change, so local_fence is left at true here.
I've tested the change with an Intel-E810-CQDA2 card, lspci show is as:
Intel Corporation Ethernet Controller E810-C for QSFP (rev 02)
Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Cc: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Mustafa Ismail <mustafa.ismail@intel.com>
Cc: Shiraz Saleem <shiraz.saleem@intel.com>
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Assisted-by: Claude:claude-sonnet-5-5
Tested-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
---
drivers/infiniband/hw/irdma/verbs.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c
index 5d71300da0ff..a524e8fc7738 100644
--- a/drivers/infiniband/hw/irdma/verbs.c
+++ b/drivers/infiniband/hw/irdma/verbs.c
@@ -4279,11 +4279,14 @@ static int irdma_post_send(struct ib_qp *ibqp,
stag_info.addr_type = IRDMA_ADDR_TYPE_VA_BASED;
stag_info.va = (void *)(uintptr_t)iwmr->ibmr.iova;
stag_info.total_len = iwmr->ibmr.length;
- stag_info.reg_addr_pa = *palloc->level1.addr;
- stag_info.first_pm_pbl_index = palloc->level1.idx;
- stag_info.local_fence = true;
- if (iwmr->npages > IRDMA_MIN_PAGES_PER_FMR)
+ if (palloc->level == PBLE_LEVEL_2) {
+ stag_info.chunk_size = 3;
+ stag_info.first_pm_pbl_index = palloc->level2.root.idx;
+ } else {
stag_info.chunk_size = 1;
+ stag_info.first_pm_pbl_index = palloc->level1.idx;
+ }
+ stag_info.local_fence = true;
err = irdma_sc_mr_fast_register(&iwqp->sc_qp, &stag_info,
true);
break;
--
2.43.0
next reply other threads:[~2026-10-07 9:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 9:53 Stefan Metzmacher [this message]
2026-10-07 10:26 ` Stefan Metzmacher
2026-10-12 6:33 ` Leon Romanovsky
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=20261007095312.1523211-1-metze@samba.org \
--to=metze@samba.org \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mustafa.ismail@intel.com \
--cc=shiraz.saleem@intel.com \
--cc=tatyana.e.nikolova@intel.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®