[PATCH AUTOSEL 6.18-5.10] RDMA/mlx5: Use QP port when decoding responder CQEs

[Sasha Levin <sashal@kernel.org>]

From: Chenguang Zhao <zhaochenguang@kylinos.cn>

[ Upstream commit 194762e6e436acde0f8f6aef44200b0058c36791 ]

The responder CQE path determines the link layer via
rdma_port_get_link_layer(). Use qp->port instead of
hardcoding port 1, which can mis-decode completions on
multi-port devices.

Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Link: https://patch.msgid.link/20260410074046.2044595-1-zhaochenguang@kylinos.cn
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting to https://agentn.us.api5.cursor.sh
(attempt 1)...
Retry attempt 1...
# Stable Backport Analysis: RDMA/mlx5: Use QP port when decoding
responder CQEs

**Local tree:** `v6.18.43` (`VERSION = 6`, `PATCHLEVEL = 18`, `SUBLEVEL
= 43`, `git describe HEAD` = `v6.18.43-1-gc7f0dac02d232`)

**Fix commit (mainline):** `194762e6e436a` — not present in this
checkout (`git merge-base --is-ancestor` returns false).

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[RDMA/mlx5]` `[use]` — use the QP's actual port instead of
hardcoded port 1 when determining link layer for responder CQE decoding.

### Step 1.2: Tags
**Record:**
- `Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>` (author)
- `Link: https://patch.msgid.link/20260410074046.2044595-1-
  zhaochenguang@kylinos.cn`
- `Signed-off-by: Leon Romanovsky <leon@kernel.org>` (RDMA maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc:
  stable@vger.kernel.org`
- Notable: maintainer applied; no fuzzer or user bug report tags

### Step 1.3: Body analysis
**Record:**
- **Bug:** `handle_responder()` calls
  `rdma_port_get_link_layer(qp->ibqp.device, 1)` — always port 1.
- **Symptom:** Responder CQEs on multi-port mlx5 devices can be mis-
  decoded when the QP is bound to a port other than 1, or when ports
  differ in link layer.
- **Root cause:** Link-layer branch selection uses the wrong port
  number.
- **Versions:** Bug present from at least v4.8 through v6.18 in this
  repo (verified via tags).

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit correctness fix, not disguised
cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/infiniband/hw/mlx5/cq.c` (+2 / -1)
- **Function:** `handle_responder()`
- **Scope:** Single-file, surgical one-line logic fix

### Step 2.2: Code flow change
**Record:**
- **Before:** `ll = rdma_port_get_link_layer(qp->ibqp.device, 1)`
- **After:** `ll = rdma_port_get_link_layer(qp->ibqp.device, qp->port)`
- **Path:** Responder CQE handling during CQ poll — normal hot path for
  incoming RDMA receives.

### Step 2.3: Bug mechanism
**Record:** **Logic / correctness fix.** `ll` controls which branch
decodes completion metadata:

```242:270:drivers/infiniband/hw/mlx5/cq.c
        if (ll != IB_LINK_LAYER_ETHERNET) {
                wc->slid = be16_to_cpu(cqe->slid);
                wc->sl = (be32_to_cpu(cqe->flags_rqpn) >> 24) & 0xf;
                return;
        }

        wc->slid = 0;
        vlan_present = cqe->l4_l3_hdr_type & 0x1;
        roce_packet_type   = (be32_to_cpu(cqe->flags_rqpn) >> 24) & 0x3;
        // ... RoCE VLAN, network_hdr_type decoding ...
```

Using port 1's link layer when the QP is on another port selects the
wrong branch, populating `ib_wc` fields incorrectly (e.g., IB
`slid`/`sl` vs RoCE `vlan_id`/`network_hdr_type`).

### Step 2.4: Fix quality
**Record:**
- Obviously correct — `qp->port` is already used in the same function
  for pkey lookup (line 236).
- mlx4 consistently uses `qp->port` for the same purpose
  (`drivers/infiniband/hw/mlx4/qp.c:3050`).
- Minimal change, no API changes, negligible regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** In this checkout, blame points to import commit
`a112b91dd6349` (tree packaging artifact). Tag inspection shows the
hardcoded `1` is present at v4.8, v4.9, v4.14, v4.19, v5.4, v5.10,
v5.15, v6.1, v6.6, v6.12, v6.18 — a long-standing bug.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag in commit message.

### Step 3.3: Related file history
**Record:** Fix commit `194762e6e436a` is on `net-next` and `all-next`.
Current HEAD (6.18.43) does not contain it. `cq.c` has had other
post-v6.18 changes on `net-next` (UMEM refactors) but this fix is
independent.

### Step 3.4: Author context
**Record:** Chenguang Zhao (Kylinos). Leon Romanovsky (mlx5/RDMA
maintainer) committed the fix. No other related commits from this author
found in this tree.

### Step 3.5: Dependencies
**Record:** None. Standalone, self-contained one-hunk change. `qp->port`
and `struct mlx5_ib_qp` exist in this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- `b4 dig -c 194762e6e436a` → https://patch.msgid.link/20260410074046.20
  44595-1-zhaochenguang@kylinos.cn
- Single v1 revision; no v2/v3
- Leon Romanovsky: "Applied, thanks!" — no objections, no stable
  nomination

### Step 4.2: Reviewers
**Record:** `b4 dig -w`: CC'd to Leon Romanovsky, Jason Gunthorpe,
linux-rdma@vger.kernel.org. Maintainer applied directly.

### Step 4.3: Bug reports
**Record:** No external bug report, syzbot, or Bugzilla link. Kylinos
authorship suggests internal/production discovery on multi-port
hardware.

### Step 4.4: Series context
**Record:** Standalone 1/1 patch, no series dependencies.

### Step 4.5: Stable list history
**Record:** No stable-list discussion found in thread mbox. No `Cc:
stable` in thread.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `handle_responder()`, called from CQE poll path.

### Step 5.2: Callers
**Record:**
- `handle_responder()` ← CQE opcode switch in poll path (line 518)
- `mlx5_ib_poll_cq()` (line 610) ← `.poll_cq` in `main.c:4352`
- Reachable from userspace via `ibv_poll_cq()` on mlx5 devices.

### Step 5.3: Callees
**Record:** `rdma_port_get_link_layer()`, `ib_find_cached_pkey()`, CQE
field decoding.

### Step 5.4: Reachability
**Record:** **Userspace-reachable** on every responder completion poll.
Trigger requires mlx5 HCA with `num_ports > 1`, QP on port ≠ 1, and (for
functional impact) different link-layer types between port 1 and
`qp->port`. Dual-port same-type configs (common IB or RoCE) are
unaffected.

### Step 5.5: Similar patterns
**Record:** mlx4 uses `qp->port` in four places for
`rdma_port_get_link_layer()`. mlx5 `handle_responder()` is the outlier;
same function already uses `qp->port` at line 236.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE

### Step 6.1: Buggy code present?
**Record:** **YES.** Current tree at
`drivers/infiniband/hw/mlx5/cq.c:172`:
```c
enum rdma_link_layer ll = rdma_port_get_link_layer(qp->ibqp.device, 1);
```

### Step 6.2: Backport complications
**Record:** **Clean apply expected** — identical context in 6.18.43. No
conflicts anticipated.

### Step 6.3: Related fixes already present?
**Record:** None. `git log --grep="QP port when decoding"` returns
nothing on current HEAD.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** `drivers/infiniband/hw/mlx5` — **IMPORTANT** (ConnectX RDMA,
widely deployed in HPC/cloud/enterprise).

### Step 7.2: Subsystem activity
**Record:** Actively maintained; mlx5 is a primary production RDMA
driver.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users of multi-port mlx5 HCAs running QPs on port 2+ where
port 1 and `qp->port` have different link layers. Subset of RDMA users,
but includes serious production deployments (HPC clusters, cloud RDMA).

### Step 8.2: Trigger conditions
**Record:** Responder CQE poll on a QP not on port 1, with mismatched
link-layer types between ports. Not every boot; requires specific multi-
port configuration. Unprivileged users can trigger via normal RDMA CQ
polling.

### Step 8.3: Failure mode severity
**Record:** Incorrect `ib_wc` metadata delivered to userspace (wrong
`slid`/`sl` vs `vlan_id`/`network_hdr_type`). **Severity: MEDIUM** — no
kernel oops/UAF, but wrong completion data can break RDMA applications
silently. Fits stable rules' "oh, that's not good" category.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** MEDIUM for affected configs; correctness fix for
  production RDMA
- **Risk:** VERY LOW (one-line, pattern-proven)
- **Ratio:** Favorable — trivial fix for a real, long-standing bug

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real, verified bug in this 6.18.43 tree
- Trivial, obviously correct fix (matches mlx4 and same-function
  `qp->port` usage)
- Userspace-reachable via CQ poll hot path
- Wrong `ib_wc` data to applications on affected multi-port configs
- Maintainer-applied, zero regression risk
- Present since at least v4.8 — long-lived latent bug

**AGAINST backport:**
- No crash, deadlock, security issue, or kernel memory corruption
- No `Reported-by:` or public bug report
- Practical impact limited to niche config (multi-port + different link
  layers + QP on port ≠ 1)
- Dual-port same-type HCAs (majority of deployments) unaffected
- No explicit stable nomination

**Unresolved:** No independent test report; exact production trigger
case from Kylinos not documented in thread.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logically correct; no
   explicit test but maintainer-applied
2. Fixes real bug affecting users? **PASS** — wrong WC metadata on
   affected multi-port setups
3. Important issue? **PASS (borderline)** — not crash/security, but
   incorrect userspace API data on production RDMA path
4. Small and contained? **PASS** — 3 lines, one file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — bug confirmed present, clean
   apply expected

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs).

### Step 9.4: Decision rationale

This is a clear oversight: `handle_responder()` hardcodes port 1 while
the same function uses `qp->port` for pkey resolution, and mlx4 does the
right thing throughout. On multi-port mlx5 devices where ports differ in
link layer and QPs are bound to port 2+, userspace receives incorrectly
decoded work completions. That is a real correctness bug on a hot
userspace-facing path, fixable with a one-line change and essentially
zero risk. It does not cause kernel crashes, but stable rules explicitly
allow fixes for notable "oh, that's not good" issues, and delivering
wrong RDMA completion metadata qualifies for RDMA production users.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message and
  `git show 194762e6e436a`
- [Phase 1] No syzbot/Reported-by/Fixes: tags found
- [Phase 2] Diff: 1-line logic change in `handle_responder()`,
  `cq.c:172`
- [Phase 2] Read `handle_responder()` lines 169–271 — confirmed branch
  impact on `ib_wc` fields
- [Phase 3] `git describe HEAD` → v6.18.43; `git merge-base --is-
  ancestor 194762e6e436a HEAD` → fix NOT in tree
- [Phase 3] Tags v4.8–v6.18 checked — hardcoded port 1 present in all
- [Phase 3] `git show 194762e6e436a` — full diff confirmed
- [Phase 4] `b4 dig -c 194762e6e436a` — lore URL found
- [Phase 4] `b4 dig -a` — single v1 revision
- [Phase 4] `b4 dig -w` — Leon Romanovsky, Jason Gunthorpe CC'd
- [Phase 4] `b4 dig -m /tmp/mlx5_cq_thread.mbox` — Leon applied, no
  stable/CC discussion
- [Phase 5] `grep handle_responder` — called from CQE poll switch at
  line 518
- [Phase 5] `mlx5_ib_poll_cq` registered as `.poll_cq` in `main.c:4352`
- [Phase 5] mlx4 uses `qp->port` at `mlx4/qp.c:3050` (and 3 other sites)
- [Phase 6] Buggy line confirmed at `cq.c:172` in current checkout
- [Phase 6] `qp->port` field confirmed in `mlx5_ib.h:526`
- [Phase 8] Impact: wrong WC metadata, MEDIUM severity, niche multi-port
  trigger
- [UNVERIFIED] Exact hardware configuration Kylinos used to discover the
  bug

**YES**

 drivers/infiniband/hw/mlx5/cq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 651d76bca114d..c6590dde68332 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -169,7 +169,8 @@ enum {
 static void handle_responder(struct ib_wc *wc, struct mlx5_cqe64 *cqe,
 			     struct mlx5_ib_qp *qp)
 {
-	enum rdma_link_layer ll = rdma_port_get_link_layer(qp->ibqp.device, 1);
+	enum rdma_link_layer ll =
+		rdma_port_get_link_layer(qp->ibqp.device, qp->port);
 	struct mlx5_ib_dev *dev = to_mdev(qp->ibqp.device);
 	struct mlx5_ib_srq *srq = NULL;
 	struct mlx5_ib_wq *wq;
-- 
2.53.0