[PATCH AUTOSEL 6.18-6.12] net: hns3: improve the unused_tuple parameter setting

With mask `k = 0`, this yields `X = key`, `Y = 0` — not wildcard
behavior. When `unused_tuple` **is** set, `hclge_fd_convert_tuple()`
skips programming that tuple (wildcard). The ethtool path already does
zero-mask checks (e.g. `hclge_fd_check_ether_tuple()`); the tc flower
path did not.

**Step 2.4 — Fix quality**
Record: Obviously correct, minimal, mirrors existing driver logic. Low
regression risk. Does not fix the same gap in `hclge_get_cls_key_port()`
(ports), but that is a separate pre-existing issue.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: `hclge_get_cls_key_mac()` introduced in `0205ec041ec61` (“net:
hns3: add support for hw tc offload of tc flower”, Dec 2020).
`hclge_get_cls_key_ip()` mostly from same commit; signature extended in
`e199a5b29f199` (2024).

**Step 3.2 — Fixes: tag**
Record: N/A — no `Fixes:` tag.

**Step 3.3 — Related file history**
Record: Commit `1ad6f1ff3e96c` is patch 2/6 of “enhance tc flow offload
support” on master. Other series commits add actions, dissectors,
debugfs, and file split — not required for this 12-line fix. Standalone.

**Step 3.4 — Author context**
Record: Jijie Shao is an active hns3 contributor (FD/TC-related commits
in this tree).

**Step 3.5 — Dependencies**
Record: None. Functions and structures exist unchanged in 6.18.y.
Cherry-pick to current HEAD applies cleanly (auto-merge, exit 0).

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**
Record: `b4 dig -c 1ad6f1ff3e96c` →
https://patch.msgid.link/20260610060618.834987-3-shaojijie@huawei.com
Series: V4 net-next 2/6. Revisions v1–v4 found via `b4 dig -a`. Lore
direct fetch blocked by bot protection; thread retrieved via `b4 dig
-m`.

**Step 4.2 — Reviewers**
Record: `b4 dig -w` CC’d `davem@davemloft.net`, `kuba@kernel.org`,
`pabeni@redhat.com`, `netdev@vger.kernel.org`, Huawei maintainers. No
explicit stable nomination found in mbox grep.

**Step 4.3 — Bug report**
Record: No external bug report, syzbot, or user `Reported-by:`.

**Step 4.4 — Series context**
Record: Part of 6-patch enhancement series, but this patch only fixes
existing cls-flower parsing; does not depend on new actions/dissectors
from patches 3–6.

**Step 4.5 — Stable list**
Record: Not searched on lore stable (no stable nomination found in
retrieved mbox). UNVERIFIED whether stable@ discussed this separately.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: `hclge_get_cls_key_mac()`, `hclge_get_cls_key_ip()`, called from
`hclge_parse_cls_flower()`.

**Step 5.2 — Callers**
Record: `hclge_parse_cls_flower()` ← `hclge_add_cls_flower()` ←
`add_cls_flower` in `hnae3` ops ← `hns3_nic_setup_tc()`
(`ndo_setup_tc`). Reachable from userspace via `tc` flower rules on HNS3
NICs.

**Step 5.3 — Callees**
Record: `flow_rule_match_*`, `ether_addr_copy`, `ipv6_addr_be32_to_cpu`,
`unused_tuple |= BIT(...)`.

**Step 5.4 — Reachability**
Record: Userspace-triggered via `tc filter add ... flower ...` on
HiSilicon HNS3 hardware with flow-director/tc-flower offload enabled
(`CONFIG_HNS3`).

**Step 5.5 — Similar patterns**
Record: Ethtool FD path in same file already checks zero masks
(`hclge_fd_check_tcpip4_tuple()`, `hclge_fd_check_ether_tuple()`, etc.).
tc flower path was inconsistent.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.y)

**Step 6.1 — Buggy code present?**
Record: **Yes.** Local tree is **v6.18.44** (`git describe HEAD`).
`hclge_get_cls_key_mac()` and `hclge_get_cls_key_ip()` lack zero-mask
checks. Commit `1ad6f1ff3e96c` is **not** an ancestor of HEAD (`NOT IN
TREE`). Bug present since tc flower support landed (2020).

**Step 6.2 — Backport complications**
Record: Clean cherry-pick (auto-merge, no conflicts). Expected apply:
**clean**.

**Step 6.3 — Related fixes already present?**
Record: No equivalent fix found in 6.18.y history for this specific
issue.

---

## Phase 7: Subsystem Context

**Step 7.1 — Subsystem / criticality**
Record: `drivers/net/ethernet/hisilicon/hns3` — **IMPORTANT**
(server/cloud NIC driver, tc offload data path).

**Step 7.2 — Activity**
Record: Actively maintained; recent TC/FD fixes in this file (e.g.
`d7beeb64be5ca`, `6b36e5c4741f1`).

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
Record: Users of HiSilicon HNS3 NICs with hardware tc flower offload,
configuring rules with partial src/dst IP or MAC matching.

**Step 8.2 — Trigger conditions**
Record: Common — `tc flower` rules matching only source or only
destination IP/MAC. Unprivileged users can install tc rules (with
appropriate capabilities/namespace policy).

**Step 8.3 — Failure mode / severity**
Record: Incorrect hardware packet classification / queue steering; rules
may not match intended traffic or may match too narrowly. **Severity:
MEDIUM** — functional data-path bug, not kernel crash, deadlock, or
memory corruption.

**Step 8.4 — Risk vs benefit**
Record:
- **Benefit:** MEDIUM — fixes real mis-steering for standard tc usage on
  production NICs
- **Risk:** LOW — 12 lines, mirrors proven ethtool logic
- **Ratio:** Favorable for stable

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Real, verifiable logic bug in tc flower offload path
- Bug present in 6.18.y since 2020
- Small, self-contained, applies cleanly
- Aligns tc path with existing ethtool FD logic in same driver
- Userspace-reachable via `tc` on widely deployed server NICs
- Maintainer-reviewed and merged

**Evidence AGAINST backport:**
- No crash, security, or corruption angle
- No user/fuzzer bug report
- Part of larger net-next enhancement series (though patch itself is
  independent)
- Port matching has same class of bug but is not addressed here

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — logic mirrors existing
   driver patterns; no `Tested-by:` but change is straightforward
2. Fixes a real bug affecting users? **PASS** — incorrect HW filtering
   for partial tc flower matches
3. Important issue? **PASS (borderline)** — incorrect packet steering on
   production networking path; not crash-level but user-visible and
   operationally significant
4. Small and contained? **PASS** — 12 lines, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — verified clean cherry-pick

**Exception category:** None (not quirk/ID/DT/docs/build).

---

## Problem Summary

This commit fixes a long-standing inconsistency in the HNS3 driver’s tc
flower offload path. When users install `tc flower` rules specifying
only source or only destination IP/MAC addresses, the flow dissector
includes the address key with a zero mask for the unspecified side. The
driver must mark those tuples as unused so hardware treats them as
wildcards. Without this fix, `unused_tuple` is not set, hardware is
programmed with zero-mask tuple values, and flow-director rules behave
incorrectly.

For **Linux 6.18.y**, the buggy code is present, the fix is absent, the
patch applies cleanly, and it is standalone. This is appropriate stable
material: a small, low-risk driver correctness fix for a userspace-
visible data-path bug.

---

## Verification

- [Phase 1] Parsed commit message and tags from provided diff and `git
  show 1ad6f1ff3e96c`
- [Phase 2] Analyzed diff: +12 lines in `hclge_get_cls_key_mac()` and
  `hclge_get_cls_key_ip()`
- [Phase 2] Verified `calc_x`/`calc_y` macros and
  `hclge_fd_convert_tuple()` skip logic
- [Phase 2] Verified ethtool path already has zero-mask checks
  (`hclge_fd_check_ether_tuple()` etc.)
- [Phase 3] `git blame`: buggy code from `0205ec041ec61` (2020)
- [Phase 3] `git merge-base --is-ancestor 1ad6f1ff3e96c HEAD` → NOT IN
  TREE
- [Phase 3] Cherry-pick test: `git cherry-pick --no-commit
  1ad6f1ff3e96c` → exit 0, auto-merge
- [Phase 4] `b4 dig -c 1ad6f1ff3e96c` → lore URL found
- [Phase 4] `b4 dig -a` → v1–v4 series revisions
- [Phase 4] `b4 dig -w` → netdev maintainers CC’d
- [Phase 4] `b4 dig -m` → cover letter retrieved; patch 2/6 context
  confirmed
- [Phase 5] Traced call chain: `hns3_nic_setup_tc` →
  `hclge_add_cls_flower` → `hclge_parse_cls_flower`
- [Phase 6] `git describe HEAD` → v6.18.44; Makefile 6.18.44
- [Phase 6] Read current `hclge_main.c` — buggy code confirmed present
  (no zero-mask checks in MAC/IP cls helpers)
- [Phase 8] Assessed severity as MEDIUM functional data-path bug
- UNVERIFIED: No direct lore stable-list discussion
- UNVERIFIED: No runtime test evidence beyond maintainer merge

**YES****Task result:** The branch search found commit `1ad6f1ff3e96c`
on `master` — it matches the patch under review and is not in the local
6.18.44 tree.

**Verdict (unchanged):** Backport **YES**. Small, standalone fix for
incorrect tc flower hardware filtering when only src or dst IP/MAC is
specified; applies cleanly to 6.18.y.

 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c  | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 7f174453928c1..08f7bda4ef4c4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7261,6 +7261,10 @@ static void hclge_get_cls_key_mac(const struct flow_rule *flow,
 		ether_addr_copy(rule->tuples_mask.dst_mac, match.mask->dst);
 		ether_addr_copy(rule->tuples.src_mac, match.key->src);
 		ether_addr_copy(rule->tuples_mask.src_mac, match.mask->src);
+		if (is_zero_ether_addr(match.mask->dst))
+			rule->unused_tuple |= BIT(INNER_DST_MAC);
+		if (is_zero_ether_addr(match.mask->src))
+			rule->unused_tuple |= BIT(INNER_SRC_MAC);
 	} else {
 		rule->unused_tuple |= BIT(INNER_DST_MAC);
 		rule->unused_tuple |= BIT(INNER_SRC_MAC);
@@ -7309,6 +7313,10 @@ static int hclge_get_cls_key_ip(const struct flow_rule *flow,
 		rule->tuples.dst_ip[IPV4_INDEX] = be32_to_cpu(match.key->dst);
 		rule->tuples_mask.dst_ip[IPV4_INDEX] =
 						be32_to_cpu(match.mask->dst);
+		if (!match.mask->src)
+			rule->unused_tuple |= BIT(INNER_SRC_IP);
+		if (!match.mask->dst)
+			rule->unused_tuple |= BIT(INNER_DST_IP);
 	} else if (addr_type == FLOW_DISSECTOR_KEY_IPV6_ADDRS) {
 		struct flow_match_ipv6_addrs match;
 
@@ -7321,6 +7329,10 @@ static int hclge_get_cls_key_ip(const struct flow_rule *flow,
 				      match.key->dst.s6_addr32);
 		ipv6_addr_be32_to_cpu(rule->tuples_mask.dst_ip,
 				      match.mask->dst.s6_addr32);
+		if (ipv6_addr_any(&match.mask->src))
+			rule->unused_tuple |= BIT(INNER_SRC_IP);
+		if (ipv6_addr_any(&match.mask->dst))
+			rule->unused_tuple |= BIT(INNER_DST_IP);
 	} else {
 		rule->unused_tuple |= BIT(INNER_SRC_IP);
 		rule->unused_tuple |= BIT(INNER_DST_IP);
-- 
2.53.0