[PATCH AUTOSEL 6.18-6.6] ipv6: clean up routes when manually removing address with a lifetime

[PATCH AUTOSEL 6.18-6.6] ipv6: clean up routes when manually removing address with a lifetime

[Sasha Levin]

From: Jakub Kicinski <kuba@kernel.org>

[ Upstream commit c7dc5b5228822d2389e6e441f10169e460bcc67a ]

When an IPv6 address with a finite lifetime (configured with valid_lft
and preferred_lft) is manually deleted, the kernel does not clean up the
associated prefix route. This results in orphaned routes (marked "proto
kernel") remaining in the routing table even after their corresponding
address has been deleted.

This is particularly problematic on networks using combination of SLAAC
and bridges.

1. Machine comes up and performs RA on eth0.
2. User creates a bridge
   - does an ip -6 addr flush dev eth0;
   - adds the eth0 under the bridge.
3. SLAAC happens on br0.

Even tho the address has "moved" to br0 there will still be a route
pointing to eth0, but eth0 is not usable for IP any more.

Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20251113031700.3736285-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Analysis of Commit: ipv6: clean up routes when manually removing
address with a lifetime

## 1. COMMIT MESSAGE ANALYSIS

**Subject:** Fixes route cleanup when IPv6 addresses with finite
lifetimes are deleted manually

**Key Problem Described:**
- When an IPv6 address configured with `valid_lft` and `preferred_lft`
  is manually deleted, the kernel fails to clean up the associated
  prefix route
- Results in orphaned routes (marked "proto kernel") remaining in the
  routing table
- Particularly problematic with SLAAC + bridges (a real-world scenario)

**Tags:**
- `Reviewed-by: David Ahern` (network subsystem maintainer)
- `Reviewed-by: Ido Schimmel` (networking contributor)
- `Signed-off-by: Jakub Kicinski` (Linux networking maintainer)

**Notable Missing Tags:**
- No `Cc: stable@vger.kernel.org`
- No `Fixes:` tag

## 2. CODE CHANGE ANALYSIS

The core fix is extremely minimal - a single condition change in
`net/ipv6/addrconf.c`:

**Before:**
```c
if (ifp->flags & IFA_F_PERMANENT && !(ifp->flags & IFA_F_NOPREFIXROUTE))
```

**After:**
```c
if (!(ifp->flags & IFA_F_NOPREFIXROUTE))
```

**Technical Mechanism:**
- `IFA_F_PERMANENT` flag is set for addresses WITHOUT a finite lifetime
- Addresses with `valid_lft`/`preferred_lft` set do NOT have
  `IFA_F_PERMANENT`
- The old code only cleaned up prefix routes for permanent (infinite
  lifetime) addresses
- Non-permanent addresses (those with lifetimes) would have their routes
  orphaned on manual deletion
- The fix removes the overly-restrictive `IFA_F_PERMANENT` check,
  ensuring route cleanup for ALL addresses that don't have
  `IFA_F_NOPREFIXROUTE`

**Root Cause:** Logic error - the condition was too restrictive, failing
to clean up routes for addresses with finite lifetimes.

## 3. CLASSIFICATION

- **Bug Fix:** Yes - fixes route leakage/orphaning
- **New Feature:** No - corrects existing cleanup behavior
- **Security:** No explicit security issue, but orphaned routes can
  cause routing problems

## 4. SCOPE AND RISK ASSESSMENT

**Lines Changed:**
- Core fix: 1 line modified (condition simplification)
- Test: ~20 lines added to selftest

**Risk Level: LOW**
- The `check_cleanup_prefix_route()` and `cleanup_prefix_route()`
  functions already exist and are tested
- The fix EXTENDS existing cleanup to more cases (non-permanent
  addresses)
- No new code paths introduced, just removes an unnecessary condition
- Well-reviewed by multiple networking maintainers

## 5. USER IMPACT

**Affected Users:**
- Anyone using IPv6 with finite address lifetimes (SLAAC, DHCPv6)
- Users managing bridges with IPv6 addresses
- Enterprise/data center environments with complex networking

**Severity:** Medium
- Orphaned routes can cause routing confusion and network connectivity
  issues
- The SLAAC + bridge scenario is common in real-world deployments
- Routes pointing to unusable interfaces cause operational problems

## 6. STABILITY INDICATORS

**Positive:**
- Three experienced networking maintainers involved (Kicinski, Ahern,
  Schimmel)
- Includes selftest (`kci_test_addrlft_route_cleanup`) for regression
  testing
- Simple, surgical change with clear intent

## 7. DEPENDENCY CHECK

- Self-contained fix with no dependencies on other commits
- The affected functions (`check_cleanup_prefix_route`, etc.) have
  existed for a long time
- Should apply cleanly to recent stable kernels

## ASSESSMENT SUMMARY

**Pros:**
1. Fixes a real, user-visible bug (orphaned routes)
2. Extremely minimal change (removes one condition)
3. Strong review from key networking maintainers
4. Low regression risk - extends existing behavior to more cases
5. Includes regression test
6. Addresses a practical scenario (SLAAC + bridges)

**Cons/Considerations:**
1. No explicit `Cc: stable@vger.kernel.org` tag - maintainers didn't
   request backport
2. No `Fixes:` tag - unknown when bug was introduced (likely long-
   standing)
3. The bug has workarounds (routes eventually expire, or can be manually
   deleted)

## VERDICT

This commit is a good candidate for stable backporting. It is:
- **Obviously correct:** The `IFA_F_PERMANENT` check makes no logical
  sense for route cleanup
- **Fixes a real bug:** Orphaned routes are a tangible problem affecting
  real users
- **Small and contained:** Single condition change in one file
- **Low risk:** Extends existing cleanup mechanism to more cases
- **Well-tested:** Reviewed by maintainers and includes regression test

The lack of stable tags is notable but not disqualifying. The fix is
clearly beneficial and the risk is minimal. Stable tree users dealing
with IPv6 address lifetimes and bridges would benefit from this fix.

**YES**

 net/ipv6/addrconf.c                      |  2 +-
 tools/testing/selftests/net/rtnetlink.sh | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 40e9c336f6c55..b66217d1b2f82 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1324,7 +1324,7 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
 		__in6_ifa_put(ifp);
 	}
 
-	if (ifp->flags & IFA_F_PERMANENT && !(ifp->flags & IFA_F_NOPREFIXROUTE))
+	if (!(ifp->flags & IFA_F_NOPREFIXROUTE))
 		action = check_cleanup_prefix_route(ifp, &expires);
 
 	list_del_rcu(&ifp->if_list);
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index 163a084d525d5..248c2b91fe42b 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -8,6 +8,7 @@ ALL_TESTS="
 	kci_test_polrouting
 	kci_test_route_get
 	kci_test_addrlft
+	kci_test_addrlft_route_cleanup
 	kci_test_promote_secondaries
 	kci_test_tc
 	kci_test_gre
@@ -323,6 +324,25 @@ kci_test_addrlft()
 	end_test "PASS: preferred_lft addresses have expired"
 }
 
+kci_test_addrlft_route_cleanup()
+{
+	local ret=0
+	local test_addr="2001:db8:99::1/64"
+	local test_prefix="2001:db8:99::/64"
+
+	run_cmd ip -6 addr add $test_addr dev "$devdummy" valid_lft 300 preferred_lft 300
+	run_cmd_grep "$test_prefix proto kernel" ip -6 route show dev "$devdummy"
+	run_cmd ip -6 addr del $test_addr dev "$devdummy"
+	run_cmd_grep_fail "$test_prefix" ip -6 route show dev "$devdummy"
+
+	if [ $ret -ne 0 ]; then
+		end_test "FAIL: route not cleaned up when address with valid_lft deleted"
+		return 1
+	fi
+
+	end_test "PASS: route cleaned up when address with valid_lft deleted"
+}
+
 kci_test_promote_secondaries()
 {
 	run_cmd ifconfig "$devdummy"
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] net: sched: Don't use WARN_ON_ONCE() for -ENOMEM in tcf_classify().

[Sasha Levin]

From: Kuniyuki Iwashima <kuniyu@google.com>

[ Upstream commit b8a7826e4b1aab3fabb29cbf0b73da9993d356de ]

As demonstrated by syzbot, WARN_ON_ONCE() in tcf_classify() can
be easily triggered by fault injection. [0]

We should not use WARN_ON_ONCE() for the simple -ENOMEM case.

Also, we provide SKB_DROP_REASON_NOMEM for the same error.

Let's remove WARN_ON_ONCE() there.

[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 UID: 0 PID: 31392 Comm: syz.8.7081 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250
 should_fail_ex+0x414/0x560
 should_failslab+0xa8/0x100
 kmem_cache_alloc_noprof+0x74/0x6e0
 skb_ext_add+0x148/0x8f0
 tcf_classify+0xeba/0x1140
 multiq_enqueue+0xfd/0x4c0 net/sched/sch_multiq.c:66
...
WARNING: CPU: 0 PID: 31392 at net/sched/cls_api.c:1869 tcf_classify+0xfd7/0x1140
Modules linked in:
CPU: 0 UID: 0 PID: 31392 Comm: syz.8.7081 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:tcf_classify+0xfd7/0x1140
Code: e8 03 42 0f b6 04 30 84 c0 0f 85 41 01 00 00 66 41 89 1f eb 05 e8 89 26 75 f8 bb ff ff ff ff e9 04 f9 ff ff e8 7a 26 75 f8 90 <0f> 0b 90 49 83 c5 44 4c 89 eb 49 c1 ed 03 43 0f b6 44 35 00 84 c0
RSP: 0018:ffffc9000b7671f0 EFLAGS: 00010293
RAX: ffffffff894addf6 RBX: 0000000000000002 RCX: ffff888025029e40
RDX: 0000000000000000 RSI: ffffffff8bbf05c0 RDI: ffffffff8bbf0580
RBP: 0000000000000000 R08: 00000000ffffffff R09: 1ffffffff1c0bfd6
R10: dffffc0000000000 R11: fffffbfff1c0bfd7 R12: ffff88805a90de5c
R13: ffff88805a90ddc0 R14: dffffc0000000000 R15: ffffc9000b7672c0
FS:  00007f20739f66c0(0000) GS:ffff88812613e000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c2d2a80 CR3: 0000000024e36000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 multiq_classify net/sched/sch_multiq.c:39 [inline]
 multiq_enqueue+0xfd/0x4c0 net/sched/sch_multiq.c:66
 dev_qdisc_enqueue+0x4e/0x260 net/core/dev.c:4118
 __dev_xmit_skb net/core/dev.c:4214 [inline]
 __dev_queue_xmit+0xe83/0x3b50 net/core/dev.c:4729
 packet_snd net/packet/af_packet.c:3076 [inline]
 packet_sendmsg+0x3e33/0x5080 net/packet/af_packet.c:3108
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:742
 ____sys_sendmsg+0x505/0x830 net/socket.c:2630
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684
 __sys_sendmsg net/socket.c:2716 [inline]
 __do_sys_sendmsg net/socket.c:2721 [inline]
 __se_sys_sendmsg net/socket.c:2719 [inline]
 __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2719
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f207578efc9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f20739f6038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f20759e5fa0 RCX: 00007f207578efc9
RDX: 0000000000000004 RSI: 00002000000000c0 RDI: 0000000000000008
RBP: 00007f20739f6090 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007f20759e6038 R14: 00007f20759e5fa0 R15: 00007f2075b0fa28
 </TASK>

Reported-by: syzbot+87e1289a044fcd0c5f62@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69003e33.050a0220.32483.00e8.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20251028035859.2067690-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms that `SKB_DROP_REASON_NOMEM` is a valid, well-defined drop
reason in the kernel. Now let me write my complete analysis:

## Summary Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: `net: sched: Don't use WARN_ON_ONCE() for -ENOMEM in
tcf_classify().`

**Key Details from the Commit Message**:
- The commit addresses a **syzbot-reported issue** where
  `WARN_ON_ONCE()` can be easily triggered by fault injection
- The issue is that `WARN_ON_ONCE()` is inappropriate for simple
  `-ENOMEM` (out-of-memory) cases
- The code already uses `SKB_DROP_REASON_NOMEM` to handle this same
  error, making the `WARN` redundant and noisy
- No `Cc: stable@vger.kernel.org` tag is present
- No `Fixes:` tag is present
- Has `Reported-by: syzbot` and `Closes:` link to bug report
- Has `Reviewed-by: Jamal Hadi Salim` (a TC subsystem maintainer)

### 2. CODE CHANGE ANALYSIS

**The Change (1 line modification)**:
```c
// Before:
if (WARN_ON_ONCE(!ext)) {
// After:
if (!ext) {
```

**Technical Analysis**:

The `tcf_classify()` function is the main traffic classifier function in
the Linux kernel's TC (Traffic Control) subsystem. It's called from:
- 16+ qdisc classifier functions (htb_classify, sfq_classify, etc.)
- The core `tc_run()` function

The problematic code path is:
1. `tcf_classify()` calls `tc_skb_ext_alloc(skb)` which internally calls
   `skb_ext_add(skb, TC_SKB_EXT)`
2. `skb_ext_add()` uses `GFP_ATOMIC` allocation, which **can
   legitimately fail** under memory pressure
3. On failure, the code correctly handles it by:
   - Setting `SKB_DROP_REASON_NOMEM`
   - Returning `TC_ACT_SHOT` (drop the packet)

**Why WARN_ON_ONCE is Wrong Here**:
- `WARN_ON_ONCE()` is intended for situations that indicate a **bug** or
  **should never happen**
- Memory allocation failures are **expected** runtime behavior,
  especially with `GFP_ATOMIC`
- The kernel's fault injection framework (failslab) intentionally
  triggers allocation failures for testing
- Using `WARN_ON_ONCE()` for expected failures creates false alarms and
  clutters logs

### 3. CLASSIFICATION

- **Type**: Bug fix (removing inappropriate WARN)
- **Category**: Code correctness / warning cleanup
- **NOT**: Feature addition, API change, security fix

### 4. SCOPE AND RISK ASSESSMENT

**Scope**:
- **1 file** modified: `net/sched/cls_api.c`
- **1 line** changed
- Pure removal of `WARN_ON_ONCE` wrapper

**Risk**: **VERY LOW**
- The error handling logic remains **completely unchanged**
- The packet is still dropped with correct `SKB_DROP_REASON_NOMEM`
- No functional behavior changes
- The only difference is suppression of the spurious warning

### 5. USER IMPACT

**Who is affected**:
- Anyone using TC (Traffic Control) subsystem
- Systems under memory pressure
- Test systems using fault injection
- Systems running syzbot or similar fuzzers

**Severity of the bug**:
- **Low-Medium**: The `WARN_ON_ONCE` produces kernel warning output
  (dmesg spam)
- It does NOT cause crashes or data corruption
- Some systems may treat kernel warnings as events requiring
  investigation/monitoring

**Practical Impact**:
- In production: Warnings in dmesg under memory pressure (rare but
  possible)
- In testing: Frequent warnings when using fault injection, polluting
  logs

### 6. STABILITY INDICATORS

- **Reviewed-by: Jamal Hadi Salim** - TC subsystem expert
- **Signed-off-by: Jakub Kicinski** - Network maintainer
- **syzbot tested** - The issue was discovered and verified by the
  fuzzing system

### 7. DEPENDENCY CHECK

**Code existence in stable trees**:
- The `WARN_ON_ONCE(!ext)` exists in:
  - 6.12.y (line 1869)
  - 6.6.y (line 1797)
  - 6.1.y (line 1644)
  - 5.15.y (line 1624)
  - 5.10.y (line 1631)
  - 5.4.y (line 1595)

**Original introduction**:
- The `WARN_ON_ONCE(!ext)` was introduced in commit `95a7233c452a5`
  (v5.4-rc1)

**Dependencies**:
- None - this is a standalone one-line fix
- The fix applies cleanly to all affected stable versions

### 8. HISTORICAL CONTEXT

The `WARN_ON_ONCE` was originally added in v5.4-rc1 when the TC skb
extension feature was introduced. At the time, the developer likely
thought allocation failure was unexpected, but in reality:
1. `GFP_ATOMIC` allocations can fail
2. The `SKB_DROP_REASON_NOMEM` was later added (in commit
   4cf24dc8934074) showing the failure is recognized as "memory
   exhaustion"
3. The warning serves no debugging purpose since the error is fully
   handled

## CONCLUSION

**Should this be backported?**

**Arguments FOR backporting**:
1. ✅ **Tiny, surgical fix** - 1 line change
2. ✅ **Zero functional change** - Error handling remains identical
3. ✅ **Fixes user-visible issue** - Removes spurious kernel warnings
4. ✅ **No risk of regression** - Only removes unnecessary WARN
5. ✅ **Applies cleanly** to all stable branches
6. ✅ **Well-tested** - Reviewed by TC maintainer, triggered by syzbot

**Arguments AGAINST backporting**:
1. ⚠️ No explicit `Cc: stable` tag
2. ⚠️ No `Fixes:` tag
3. ⚠️ Not a security issue
4. ⚠️ Not a crash or data corruption bug
5. ⚠️ Warnings are "noise" rather than serious bugs

**Verdict**:

While this commit lacks explicit stable tags, it represents an extremely
low-risk improvement that suppresses inappropriate kernel warnings. The
change:
- Is trivial (1 line)
- Has zero risk of regression
- Improves kernel log cleanliness under stress/testing
- Follows proper Linux coding guidelines (WARN should be for bugs, not
  expected conditions)

The lack of `Cc: stable` may simply be an oversight, as this type of fix
is commonly accepted in stable trees. The benefits (cleaner logs, proper
handling) outweigh the minimal effort of backporting.

**YES**

 net/sched/cls_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index ecec0a1e1c1a0..f751cd5eeac8d 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -1866,7 +1866,7 @@ int tcf_classify(struct sk_buff *skb,
 			struct tc_skb_cb *cb = tc_skb_cb(skb);
 
 			ext = tc_skb_ext_alloc(skb);
-			if (WARN_ON_ONCE(!ext)) {
+			if (!ext) {
 				tcf_set_drop_reason(skb, SKB_DROP_REASON_NOMEM);
 				return TC_ACT_SHOT;
 			}
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] net: amd-xgbe: use EOPNOTSUPP instead of ENOTSUPP in xgbe_phy_mii_read_c45

[Sasha Levin]

From: Alok Tiwari <alok.a.tiwari@oracle.com>

[ Upstream commit bd853a59a87ecf9fc060dd54b10a3a94e9786182 ]

The MDIO read callback xgbe_phy_mii_read_c45() can propagate its return
value up through phylink_mii_ioctl() to user space via netdev ioctls such
as SIOCGMIIREG. Returning ENOTSUPP results in user space seeing
"Unknown error", since ENOTSUPP is not a standard errno value.

Replace ENOTSUPP with EOPNOTSUPP to align with the MDIO core’s
usage and ensure user space receives a proper "Operation not supported"
error instead of an unknown code.

Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20251015025751.1532149-1-alok.a.tiwari@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need for a complete analysis. Let me
compile my findings:

## Complete Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** `net: amd-xgbe: use EOPNOTSUPP instead of ENOTSUPP in
xgbe_phy_mii_read_c45`

**Key points from the commit message:**
- The MDIO read callback `xgbe_phy_mii_read_c45()` can propagate its
  return value up through `phylink_mii_ioctl()` to **user space** via
  netdev ioctls (SIOCGMIIREG)
- Returning ENOTSUPP (error code 524) results in **user space seeing
  "Unknown error"** since ENOTSUPP is not a standard errno value
- The fix replaces ENOTSUPP (524, kernel-internal) with EOPNOTSUPP (95,
  standard POSIX errno)

**Tags present:**
- `Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>`
- `Reviewed-by: Simon Horman <horms@kernel.org>` - Important! This is a
  well-known networking reviewer
- `Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>` - AMD
  maintainer acknowledgment
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>` - Networking
  maintainer

**Missing tags:**
- No `Cc: stable@vger.kernel.org`
- No `Fixes:` tag (though one should have been added: `Fixes:
  070f6186a2f1d ("amd-xgbe: Separate C22 and C45 transactions")`)

### 2. CODE CHANGE ANALYSIS

**The diff (single line change):**
```c
- ret = -ENOTSUPP;
+               ret = -EOPNOTSUPP;
```

**Location:** `drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c`, function
`xgbe_phy_mii_read_c45()`

**Context Analysis:**
The function handles MII (Media Independent Interface) Clause 45 read
operations:

```c
static int xgbe_phy_mii_read_c45(struct mii_bus *mii, int addr, int
devad,
                                 int reg)
{
        ...
        if (phy_data->conn_type == XGBE_CONN_TYPE_SFP)
                ret = -EOPNOTSUPP;   // Already correct
        else if (phy_data->conn_type & XGBE_CONN_TYPE_MDIO)
                ret = xgbe_phy_mdio_mii_read_c45(pdata, addr, devad,
reg);
        else
                ret = -ENOTSUPP;     // BUG: should be -EOPNOTSUPP
```

**Root cause of the bug:**
- Commit `070f6186a2f1d` ("amd-xgbe: Separate C22 and C45 transactions")
  introduced this function in January 2023
- Andrew Lunn correctly used `EOPNOTSUPP` for the SFP case
- But **inconsistently/accidentally** used `ENOTSUPP` for the final else
  branch
- This is clearly an oversight/typo during the refactoring

**Technical explanation of ENOTSUPP vs EOPNOTSUPP:**
- `ENOTSUPP` (524): Defined in `include/linux/errno.h` as a **kernel-
  internal error code** originally for NFSv3 protocol
- `EOPNOTSUPP` (95): Defined in `include/uapi/asm-generic/errno.h` as a
  **standard POSIX errno** "Operation not supported"
- When kernel code returns errors through syscalls/ioctls, it must use
  standard POSIX errno values
- User-space `strerror()` doesn't know what errno 524 means → "Unknown
  error 524"

### 3. CLASSIFICATION

- **Type:** Bug fix (incorrect error code returned to userspace)
- **NOT a feature addition**
- **NOT a device ID, quirk, or DT update**
- This is fixing **incorrect API behavior** - returning a non-standard
  errno to userspace

### 4. SCOPE AND RISK ASSESSMENT

**Size:**
- 1 line changed
- 1 file touched
- **Minimal scope**

**Risk:**
- **EXTREMELY LOW** - This is a pure error code change
- Cannot cause crashes, data corruption, or regressions
- The error path itself is unchanged; only the error code returned
  differs
- Changes from an unknown error (524) to a proper descriptive error (95)

**Similar precedents:**
I found multiple similar fixes already merged:
- `f82acf6fb4211` - ixgbe: use EOPNOTSUPP instead of ENOTSUPP
- `21d08d1c4c29f` - igc: use EOPNOTSUPP instead of ENOTSUPP
- `bc73c5885c606` - igb: use EOPNOTSUPP instead of ENOTSUPP
- `ab15aabac028a` - mtd: rawnand: qcom: Use EOPNOTSUPP instead of
  ENOTSUPP

All these have `Fixes:` tags and address the same class of bug.

### 5. USER IMPACT

**Who is affected:**
- Users of AMD XGBE network devices (10Gb Ethernet)
- Any tool or application using SIOCGMIIREG/SIOCGMIIPHY ioctls
- Diagnostic tools like `mii-tool`, `ethtool`, or custom MDIO access
  utilities

**Severity:**
- When the hardware connection type is neither SFP nor MDIO, the user
  sees:
  - **Before fix:** "Unknown error 524" - confusing, hard to debug
  - **After fix:** "Operation not supported" - clear, standard message

**Real-world impact:**
- This is a **user-visible bug** affecting error reporting
- While not a crash or data corruption, it degrades user experience
- Makes debugging and troubleshooting harder

### 6. STABILITY INDICATORS

- `Reviewed-by: Simon Horman` - Very experienced networking reviewer
- `Acked-by: Shyam Sundar S K` - AMD driver maintainer
- `Signed-off-by: Jakub Kicinski` - Net maintainer
- The change is trivially correct - single character difference in error
  code

### 7. DEPENDENCY CHECK

**Dependencies:** None
- The change is self-contained
- No other commits are required
- The affected code exists in all stable kernels from 6.3 onwards (where
  `070f6186a2f1d` was merged)

**Affected stable trees:**
- 6.6.y: **Yes** - Contains the buggy commit, needs this fix
- 6.10.y through 6.18.y: **Yes** - All affected
- 6.1.y and earlier: **No** - The buggy code doesn't exist (function was
  introduced in 6.3)

### FINAL ASSESSMENT

**Pros for backporting:**
1. ✅ Fixes a **real user-visible bug** - users see "Unknown error"
   messages
2. ✅ **Extremely small and surgical** - single 1-line change
3. ✅ **Obviously correct** - changing from kernel-internal errno to
   standard POSIX errno
4. ✅ **Zero risk** - cannot introduce regressions
5. ✅ **Well reviewed** - by networking and AMD maintainers
6. ✅ **Precedent exists** - similar fixes have been applied to stable
   trees
7. ✅ **No dependencies** - applies cleanly to all affected stable trees

**Cons:**
1. ⚠️ No `Cc: stable@vger.kernel.org` tag - author didn't explicitly
   request stable backport
2. ⚠️ No `Fixes:` tag - though it clearly should have had one pointing
   to `070f6186a2f1d`
3. ⚠️ Minor severity - not a crash or security issue

**Conclusion:**

This commit fixes a clear bug where an incorrect kernel-internal error
code (ENOTSUPP, 524) is returned to userspace instead of the proper
POSIX errno (EOPNOTSUPP, 95). This causes user-space tools to display
"Unknown error 524" instead of "Operation not supported", degrading user
experience and making debugging harder.

The fix is:
- Trivially small (1 line)
- Obviously correct
- Zero risk of regression
- Well-reviewed by subsystem experts
- Has precedent with identical fixes in other drivers

While the commit lacks explicit `Cc: stable` and `Fixes:` tags, it meets
all the criteria from stable-kernel-rules.rst: it fixes "a real bug that
bothers people", is small, obviously correct, and tested (reviewed by
multiple maintainers).

**YES**

 drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
index a56efc1bee339..35a381a83647d 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
@@ -668,7 +668,7 @@ static int xgbe_phy_mii_read_c45(struct mii_bus *mii, int addr, int devad,
 	else if (phy_data->conn_type & XGBE_CONN_TYPE_MDIO)
 		ret = xgbe_phy_mdio_mii_read_c45(pdata, addr, devad, reg);
 	else
-		ret = -ENOTSUPP;
+		ret = -EOPNOTSUPP;
 
 	xgbe_phy_put_comm_ownership(pdata);
 
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] cxgb4: Rename sched_class to avoid type clash

[Sasha Levin]

From: Alan Maguire <alan.maguire@oracle.com>

[ Upstream commit 380d19db6e6c089c7d2902e02a85fd2bde3e519b ]

drivers/net/ethernet/chelsio/cxgb4/sched.h declares a sched_class
struct which has a type name clash with struct sched_class
in kernel/sched/sched.h (a type used in a field in task_struct).

When cxgb4 is a builtin we end up with both sched_class types,
and as a result of this we wind up with DWARF (and derived from
that BTF) with a duplicate incorrect task_struct representation.
When cxgb4 is built-in this type clash can cause kernel builds to
fail as resolve_btfids will fail when confused which task_struct
to use. See [1] for more details.

As such, renaming sched_class to ch_sched_class (in line with
other structs like ch_sched_flowc) makes sense.

[1] https://lore.kernel.org/bpf/2412725b-916c-47bd-91c3-c2d57e3e6c7b@acm.org/

Reported-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Potnuri Bharat Teja <bharat@chelsio.com>
Link: https://patch.msgid.link/20251121181231.64337-1-alan.maguire@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: cxgb4 sched_class rename

### 1. COMMIT MESSAGE ANALYSIS

The commit addresses a **type name clash** between:
- `struct sched_class` in `drivers/net/ethernet/chelsio/cxgb4/sched.h`
  (cxgb4 driver's scheduling class)
- `struct sched_class` in `kernel/sched/sched.h` (core scheduler's
  scheduling class used in task_struct)

**Problem:** When cxgb4 is built-in (CONFIG_CHELSIO_T4=y), both types
exist in the same compilation unit. This causes:
1. Duplicate DWARF/BTF type representations
2. **Build failures** because `resolve_btfids` tool cannot determine
   which `task_struct` to use

**Signals:**
- **Reported-by:** Bart Van Assche (real user hit this issue)
- **Reviewed-by/Acked-by:** Present from both reporter and driver
  maintainer
- **Link:** References actual bug report on lore.kernel.org
- **No Cc: stable** tag
- **No Fixes:** tag

### 2. CODE CHANGE ANALYSIS

The fix is purely mechanical - a simple rename:
- `struct sched_class` → `struct ch_sched_class` (following existing
  naming convention like `ch_sched_flowc`)

Changes across 5 files are all straightforward variable type name
replacements. The diff shows ~20 locations where the type name is
changed, with absolutely no logic modifications.

### 3. CLASSIFICATION

This is a **BUILD FIX** - one of the explicitly allowed categories for
stable backporting. The build fails when:
- cxgb4 driver is built-in
- BTF debugging is enabled (CONFIG_DEBUG_INFO_BTF=y)

The `resolve_btfids` tool fails, preventing successful kernel
compilation.

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Assessment |
|--------|------------|
| Lines changed | ~40 (all renames) |
| Files touched | 5 (all within cxgb4 driver) |
| Logic changes | **ZERO** |
| External API changes | **NONE** |
| Runtime risk | **NONE** - purely compile-time symbol naming |

**Risk Level: EXTREMELY LOW** - This cannot cause any runtime regression
as it's purely a symbol rename with no behavioral changes whatsoever.

### 5. USER IMPACT

**Affected users:**
- Those building kernels with cxgb4 built-in AND BTF enabled
- This is a realistic configuration for users doing BPF/tracing work
  with Chelsio network hardware

**Severity:** BUILD FAILURE - Complete inability to compile the kernel
for affected configurations.

### 6. STABILITY INDICATORS

- Has Reviewed-by and Acked-by tags
- Change is mechanical and obviously correct
- Merged through proper netdev maintainer path
- The naming follows existing driver conventions (`ch_sched_*`)

### 7. DEPENDENCY CHECK

The change is self-contained within the cxgb4 driver. No external
dependencies. The cxgb4 scheduler code has existed in stable trees for
years, so this fix should apply cleanly.

### Decision Analysis

**FOR backporting:**
1. **Build fix** - explicitly allowed in stable rules
2. **Zero runtime risk** - purely a type rename, no logic changes
3. **Fixes real bug** - reported by actual user, blocks compilation
4. **Small and contained** - all changes within one driver
5. **Obviously correct** - mechanical rename following existing
   conventions

**AGAINST backporting:**
1. No `Cc: stable` tag from maintainer
2. Affected configuration (built-in cxgb4 + BTF) is somewhat niche
3. Issue may only manifest with newer toolchains

### Conclusion

While the maintainer didn't add `Cc: stable`, this is a **legitimate
build fix** that prevents kernel compilation for users with specific
(but valid) configurations. Build fixes are explicitly listed as
acceptable stable material in the kernel's stable rules. The change is
mechanical, trivial, and carries effectively zero risk of any
regression. Users who update their build toolchain on stable kernels
could encounter this failure.

The risk/benefit ratio strongly favors backporting: **zero risk** vs
**fixing build failures**.

**YES**

 .../net/ethernet/chelsio/cxgb4/cxgb4_main.c   |  2 +-
 .../chelsio/cxgb4/cxgb4_tc_matchall.c         |  4 +-
 .../ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c  |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/sched.c    | 44 +++++++++----------
 drivers/net/ethernet/chelsio/cxgb4/sched.h    | 12 ++---
 5 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 392723ef14e51..ac0c7fe5743bd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3485,7 +3485,7 @@ static int cxgb_set_tx_maxrate(struct net_device *dev, int index, u32 rate)
 	struct adapter *adap = pi->adapter;
 	struct ch_sched_queue qe = { 0 };
 	struct ch_sched_params p = { 0 };
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	u32 req_rate;
 	int err = 0;
 
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
index 1672d3afe5bef..f8dcf0b4abcdc 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
@@ -56,7 +56,7 @@ static int cxgb4_matchall_egress_validate(struct net_device *dev,
 	struct port_info *pi = netdev2pinfo(dev);
 	struct flow_action_entry *entry;
 	struct ch_sched_queue qe;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	u64 max_link_rate;
 	u32 i, speed;
 	int ret;
@@ -180,7 +180,7 @@ static int cxgb4_matchall_alloc_tc(struct net_device *dev,
 	struct port_info *pi = netdev2pinfo(dev);
 	struct adapter *adap = netdev2adap(dev);
 	struct flow_action_entry *entry;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int ret;
 	u32 i;
 
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c
index 338b04f339b3d..a2dcd2e242631 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c
@@ -330,7 +330,7 @@ static int cxgb4_mqprio_alloc_tc(struct net_device *dev,
 	struct cxgb4_tc_port_mqprio *tc_port_mqprio;
 	struct port_info *pi = netdev2pinfo(dev);
 	struct adapter *adap = netdev2adap(dev);
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int ret;
 	u8 i;
 
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index a1b14468d1fff..38a30aeee1220 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -44,7 +44,7 @@ static int t4_sched_class_fw_cmd(struct port_info *pi,
 {
 	struct adapter *adap = pi->adapter;
 	struct sched_table *s = pi->sched_tbl;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int err = 0;
 
 	e = &s->tab[p->u.params.class];
@@ -122,7 +122,7 @@ static void *t4_sched_entry_lookup(struct port_info *pi,
 				   const u32 val)
 {
 	struct sched_table *s = pi->sched_tbl;
-	struct sched_class *e, *end;
+	struct ch_sched_class *e, *end;
 	void *found = NULL;
 
 	/* Look for an entry with matching @val */
@@ -166,8 +166,8 @@ static void *t4_sched_entry_lookup(struct port_info *pi,
 	return found;
 }
 
-struct sched_class *cxgb4_sched_queue_lookup(struct net_device *dev,
-					     struct ch_sched_queue *p)
+struct ch_sched_class *cxgb4_sched_queue_lookup(struct net_device *dev,
+						struct ch_sched_queue *p)
 {
 	struct port_info *pi = netdev2pinfo(dev);
 	struct sched_queue_entry *qe = NULL;
@@ -187,7 +187,7 @@ static int t4_sched_queue_unbind(struct port_info *pi, struct ch_sched_queue *p)
 	struct sched_queue_entry *qe = NULL;
 	struct adapter *adap = pi->adapter;
 	struct sge_eth_txq *txq;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int err = 0;
 
 	if (p->queue < 0 || p->queue >= pi->nqsets)
@@ -218,7 +218,7 @@ static int t4_sched_queue_bind(struct port_info *pi, struct ch_sched_queue *p)
 	struct sched_queue_entry *qe = NULL;
 	struct adapter *adap = pi->adapter;
 	struct sge_eth_txq *txq;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	unsigned int qid;
 	int err = 0;
 
@@ -260,7 +260,7 @@ static int t4_sched_flowc_unbind(struct port_info *pi, struct ch_sched_flowc *p)
 {
 	struct sched_flowc_entry *fe = NULL;
 	struct adapter *adap = pi->adapter;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int err = 0;
 
 	if (p->tid < 0 || p->tid >= adap->tids.neotids)
@@ -288,7 +288,7 @@ static int t4_sched_flowc_bind(struct port_info *pi, struct ch_sched_flowc *p)
 	struct sched_table *s = pi->sched_tbl;
 	struct sched_flowc_entry *fe = NULL;
 	struct adapter *adap = pi->adapter;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	int err = 0;
 
 	if (p->tid < 0 || p->tid >= adap->tids.neotids)
@@ -322,7 +322,7 @@ static int t4_sched_flowc_bind(struct port_info *pi, struct ch_sched_flowc *p)
 }
 
 static void t4_sched_class_unbind_all(struct port_info *pi,
-				      struct sched_class *e,
+				      struct ch_sched_class *e,
 				      enum sched_bind_type type)
 {
 	if (!e)
@@ -476,12 +476,12 @@ int cxgb4_sched_class_unbind(struct net_device *dev, void *arg,
 }
 
 /* If @p is NULL, fetch any available unused class */
-static struct sched_class *t4_sched_class_lookup(struct port_info *pi,
-						const struct ch_sched_params *p)
+static struct ch_sched_class *t4_sched_class_lookup(struct port_info *pi,
+						    const struct ch_sched_params *p)
 {
 	struct sched_table *s = pi->sched_tbl;
-	struct sched_class *found = NULL;
-	struct sched_class *e, *end;
+	struct ch_sched_class *found = NULL;
+	struct ch_sched_class *e, *end;
 
 	if (!p) {
 		/* Get any available unused class */
@@ -522,10 +522,10 @@ static struct sched_class *t4_sched_class_lookup(struct port_info *pi,
 	return found;
 }
 
-static struct sched_class *t4_sched_class_alloc(struct port_info *pi,
-						struct ch_sched_params *p)
+static struct ch_sched_class *t4_sched_class_alloc(struct port_info *pi,
+						   struct ch_sched_params *p)
 {
-	struct sched_class *e = NULL;
+	struct ch_sched_class *e = NULL;
 	u8 class_id;
 	int err;
 
@@ -579,8 +579,8 @@ static struct sched_class *t4_sched_class_alloc(struct port_info *pi,
  * scheduling class with matching @p is found, then the matching class is
  * returned.
  */
-struct sched_class *cxgb4_sched_class_alloc(struct net_device *dev,
-					    struct ch_sched_params *p)
+struct ch_sched_class *cxgb4_sched_class_alloc(struct net_device *dev,
+					       struct ch_sched_params *p)
 {
 	struct port_info *pi = netdev2pinfo(dev);
 	u8 class_id;
@@ -607,7 +607,7 @@ void cxgb4_sched_class_free(struct net_device *dev, u8 classid)
 	struct port_info *pi = netdev2pinfo(dev);
 	struct sched_table *s = pi->sched_tbl;
 	struct ch_sched_params p;
-	struct sched_class *e;
+	struct ch_sched_class *e;
 	u32 speed;
 	int ret;
 
@@ -640,7 +640,7 @@ void cxgb4_sched_class_free(struct net_device *dev, u8 classid)
 	}
 }
 
-static void t4_sched_class_free(struct net_device *dev, struct sched_class *e)
+static void t4_sched_class_free(struct net_device *dev, struct ch_sched_class *e)
 {
 	struct port_info *pi = netdev2pinfo(dev);
 
@@ -660,7 +660,7 @@ struct sched_table *t4_init_sched(unsigned int sched_size)
 	s->sched_size = sched_size;
 
 	for (i = 0; i < s->sched_size; i++) {
-		memset(&s->tab[i], 0, sizeof(struct sched_class));
+		memset(&s->tab[i], 0, sizeof(struct ch_sched_class));
 		s->tab[i].idx = i;
 		s->tab[i].state = SCHED_STATE_UNUSED;
 		INIT_LIST_HEAD(&s->tab[i].entry_list);
@@ -682,7 +682,7 @@ void t4_cleanup_sched(struct adapter *adap)
 			continue;
 
 		for (i = 0; i < s->sched_size; i++) {
-			struct sched_class *e;
+			struct ch_sched_class *e;
 
 			e = &s->tab[i];
 			if (e->state == SCHED_STATE_ACTIVE)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.h b/drivers/net/ethernet/chelsio/cxgb4/sched.h
index 6b3c778815f09..4d3b5a7575366 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.h
@@ -71,7 +71,7 @@ struct sched_flowc_entry {
 	struct ch_sched_flowc param;
 };
 
-struct sched_class {
+struct ch_sched_class {
 	u8 state;
 	u8 idx;
 	struct ch_sched_params info;
@@ -82,7 +82,7 @@ struct sched_class {
 
 struct sched_table {      /* per port scheduling table */
 	u8 sched_size;
-	struct sched_class tab[] __counted_by(sched_size);
+	struct ch_sched_class tab[] __counted_by(sched_size);
 };
 
 static inline bool can_sched(struct net_device *dev)
@@ -103,15 +103,15 @@ static inline bool valid_class_id(struct net_device *dev, u8 class_id)
 	return true;
 }
 
-struct sched_class *cxgb4_sched_queue_lookup(struct net_device *dev,
-					     struct ch_sched_queue *p);
+struct ch_sched_class *cxgb4_sched_queue_lookup(struct net_device *dev,
+						struct ch_sched_queue *p);
 int cxgb4_sched_class_bind(struct net_device *dev, void *arg,
 			   enum sched_bind_type type);
 int cxgb4_sched_class_unbind(struct net_device *dev, void *arg,
 			     enum sched_bind_type type);
 
-struct sched_class *cxgb4_sched_class_alloc(struct net_device *dev,
-					    struct ch_sched_params *p);
+struct ch_sched_class *cxgb4_sched_class_alloc(struct net_device *dev,
+					       struct ch_sched_params *p);
 void cxgb4_sched_class_free(struct net_device *dev, u8 classid);
 
 struct sched_table *t4_init_sched(unsigned int size);
-- 
2.51.0