[PATCH AUTOSEL 6.19-5.10] myri10ge: avoid uninitialized variable use

[PATCH AUTOSEL 6.19-5.10] myri10ge: avoid uninitialized variable use

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ]

While compile testing on less common architectures, I noticed that gcc-10 on
s390 finds a bug that all other configurations seem to miss:

drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list':
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized]
  391 |  buf->data0 = htonl(data->data0);
      |                         ^~
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized]
  392 |  buf->data1 = htonl(data->data1);
      |                         ^~
drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings':
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized]
  392 |  buf->data1 = htonl(data->data1);
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here
 1939 |  struct myri10ge_cmd cmd;
      |                      ^~~
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized]
  393 |  buf->data2 = htonl(data->data2);
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here
 1939 |  struct myri10ge_cmd cmd;

It would be nice to understand how to make other compilers catch this as
well, but for the moment I'll just shut up the warning by fixing the
undefined behavior in this driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@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:

### Understanding the Bug

The analysis reveals this is a **real, meaningful bug**, not just a
compiler warning cleanup:

1. **`struct myri10ge_cmd`** has three `u32` fields: `data0`, `data1`,
   `data2`
2. **`myri10ge_send_cmd()`** unconditionally copies ALL THREE fields to
   hardware via:
  ```c
  buf->data0 = htonl(data->data0);
  buf->data1 = htonl(data->data1);
  buf->data2 = htonl(data->data2);
  ```
  Then sends them to the NIC via `myri10ge_pio_copy()`.

3. In many call sites, the `cmd` struct is declared on the stack but
   **not all fields are initialized** before being passed to
   `myri10ge_send_cmd()`. This means **random stack garbage is sent to
   hardware**.

### Bug Impact

- **Undefined behavior**: Uninitialized stack variables being used is
  undefined behavior in C
- **Hardware commands with garbage data**: The NIC firmware receives
  commands with random data in unused fields, which could cause
  unpredictable behavior depending on firmware implementation
- **Potential data corruption or connectivity issues**: If the firmware
  interprets garbage values in unexpected ways
- **Build failure**: On gcc-10 on s390 with `-Werror`, this prevents
  compilation entirely

### Scope of Changes

The fix is purely additive — it adds zero-initialization of `cmd.data0`,
`cmd.data1`, `cmd.data2` at each call site where they were previously
uninitialized. The changes span **one file** with simple, repetitive
initialization statements. There's also a minor cleanup moving the `cmd`
variable declaration to a narrower scope in `myri10ge_close()`.

Functions fixed:
- `myri10ge_get_firmware_capabilities()`
- `myri10ge_update_mac_address()`
- `myri10ge_change_pause()`
- `myri10ge_change_promisc()`
- `myri10ge_allocate_rings()`
- `myri10ge_get_txrx()`
- `myri10ge_open()`
- `myri10ge_close()`
- `myri10ge_set_multicast_list()`

### Stable Kernel Criteria Assessment

| Criterion | Assessment |
|-----------|-----------|
| Obviously correct? | Yes — initializing variables to zero before use
is trivially correct |
| Fixes a real bug? | Yes — undefined behavior (uninitialized data sent
to hardware) and build failure on s390 |
| Small and contained? | Yes — single file, simple initialization
additions |
| No new features? | Correct — purely a bug fix |
| Risk of regression? | Very low — adding zero-initialization cannot
break correct code |

### Risk vs Benefit

- **Risk**: Extremely low. Zero-initializing struct fields before
  passing them to a function is the safest possible change. The only
  conceivable risk is if the hardware somehow relied on receiving
  specific non-zero garbage values, which would be absurd.
- **Benefit**: Fixes undefined behavior, prevents hardware from
  receiving garbage command data, and fixes a build failure on s390 with
  gcc-10.

### Concerns

- The myri10ge driver is for Myricom 10-Gigabit Ethernet adapters, which
  are older hardware (Myricom was acquired by CSPI years ago). However,
  users with this hardware in stable kernels still benefit from correct
  behavior.
- No dependency on other commits — this is fully self-contained.
- Note the use of commas instead of semicolons in some initializations
  (e.g., `cmd.data0 = 0,` instead of `cmd.data0 = 0;`) — this is
  syntactically valid C (comma operator) but unusual. It won't cause
  issues.

### Conclusion

This commit fixes real undefined behavior where uninitialized stack data
is sent to network hardware. It's a textbook example of a safe,
contained bug fix: zero-initializing variables before use in a single
driver file. The fix prevents both runtime undefined behavior and a
build failure on certain architectures. The risk of regression is
negligible.

**YES**

 .../net/ethernet/myricom/myri10ge/myri10ge.c  | 28 ++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 7be30a8df2685..2f0cdbd4e2ac9 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -688,6 +688,9 @@ static int myri10ge_get_firmware_capabilities(struct myri10ge_priv *mgp)
 
 	/* probe for IPv6 TSO support */
 	mgp->features = NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_TSO;
+	cmd.data0 = 0,
+	cmd.data1 = 0,
+	cmd.data2 = 0,
 	status = myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_MAX_TSO6_HDR_SIZE,
 				   &cmd, 0);
 	if (status == 0) {
@@ -806,6 +809,7 @@ static int myri10ge_update_mac_address(struct myri10ge_priv *mgp,
 		     | (addr[2] << 8) | addr[3]);
 
 	cmd.data1 = ((addr[4] << 8) | (addr[5]));
+	cmd.data2 = 0;
 
 	status = myri10ge_send_cmd(mgp, MXGEFW_SET_MAC_ADDRESS, &cmd, 0);
 	return status;
@@ -817,6 +821,9 @@ static int myri10ge_change_pause(struct myri10ge_priv *mgp, int pause)
 	int status, ctl;
 
 	ctl = pause ? MXGEFW_ENABLE_FLOW_CONTROL : MXGEFW_DISABLE_FLOW_CONTROL;
+	cmd.data0 = 0,
+	cmd.data1 = 0,
+	cmd.data2 = 0,
 	status = myri10ge_send_cmd(mgp, ctl, &cmd, 0);
 
 	if (status) {
@@ -834,6 +841,9 @@ myri10ge_change_promisc(struct myri10ge_priv *mgp, int promisc, int atomic)
 	int status, ctl;
 
 	ctl = promisc ? MXGEFW_ENABLE_PROMISC : MXGEFW_DISABLE_PROMISC;
+	cmd.data0 = 0;
+	cmd.data1 = 0;
+	cmd.data2 = 0;
 	status = myri10ge_send_cmd(mgp, ctl, &cmd, atomic);
 	if (status)
 		netdev_err(mgp->dev, "Failed to set promisc mode\n");
@@ -1946,6 +1956,8 @@ static int myri10ge_allocate_rings(struct myri10ge_slice_state *ss)
 	/* get ring sizes */
 	slice = ss - mgp->ss;
 	cmd.data0 = slice;
+	cmd.data1 = 0;
+	cmd.data2 = 0;
 	status = myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SEND_RING_SIZE, &cmd, 0);
 	tx_ring_size = cmd.data0;
 	cmd.data0 = slice;
@@ -2238,12 +2250,16 @@ static int myri10ge_get_txrx(struct myri10ge_priv *mgp, int slice)
 	status = 0;
 	if (slice == 0 || (mgp->dev->real_num_tx_queues > 1)) {
 		cmd.data0 = slice;
+		cmd.data1 = 0;
+		cmd.data2 = 0;
 		status = myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SEND_OFFSET,
 					   &cmd, 0);
 		ss->tx.lanai = (struct mcp_kreq_ether_send __iomem *)
 		    (mgp->sram + cmd.data0);
 	}
 	cmd.data0 = slice;
+	cmd.data1 = 0;
+	cmd.data2 = 0;
 	status |= myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_SMALL_RX_OFFSET,
 				    &cmd, 0);
 	ss->rx_small.lanai = (struct mcp_kreq_ether_recv __iomem *)
@@ -2312,6 +2328,7 @@ static int myri10ge_open(struct net_device *dev)
 	if (mgp->num_slices > 1) {
 		cmd.data0 = mgp->num_slices;
 		cmd.data1 = MXGEFW_SLICE_INTR_MODE_ONE_PER_SLICE;
+		cmd.data2 = 0;
 		if (mgp->dev->real_num_tx_queues > 1)
 			cmd.data1 |= MXGEFW_SLICE_ENABLE_MULTIPLE_TX_QUEUES;
 		status = myri10ge_send_cmd(mgp, MXGEFW_CMD_ENABLE_RSS_QUEUES,
@@ -2414,6 +2431,8 @@ static int myri10ge_open(struct net_device *dev)
 
 	/* now give firmware buffers sizes, and MTU */
 	cmd.data0 = dev->mtu + ETH_HLEN + VLAN_HLEN;
+	cmd.data1 = 0;
+	cmd.data2 = 0;
 	status = myri10ge_send_cmd(mgp, MXGEFW_CMD_SET_MTU, &cmd, 0);
 	cmd.data0 = mgp->small_bytes;
 	status |=
@@ -2472,7 +2491,6 @@ static int myri10ge_open(struct net_device *dev)
 static int myri10ge_close(struct net_device *dev)
 {
 	struct myri10ge_priv *mgp = netdev_priv(dev);
-	struct myri10ge_cmd cmd;
 	int status, old_down_cnt;
 	int i;
 
@@ -2491,8 +2509,13 @@ static int myri10ge_close(struct net_device *dev)
 
 	netif_tx_stop_all_queues(dev);
 	if (mgp->rebooted == 0) {
+		struct myri10ge_cmd cmd;
+
 		old_down_cnt = mgp->down_cnt;
 		mb();
+		cmd.data0 = 0;
+		cmd.data1 = 0;
+		cmd.data2 = 0;
 		status =
 		    myri10ge_send_cmd(mgp, MXGEFW_CMD_ETHERNET_DOWN, &cmd, 0);
 		if (status)
@@ -2956,6 +2979,9 @@ static void myri10ge_set_multicast_list(struct net_device *dev)
 
 	/* Disable multicast filtering */
 
+	cmd.data0 = 0;
+	cmd.data1 = 0;
+	cmd.data2 = 0;
 	err = myri10ge_send_cmd(mgp, MXGEFW_ENABLE_ALLMULTI, &cmd, 1);
 	if (err != 0) {
 		netdev_err(dev, "Failed MXGEFW_ENABLE_ALLMULTI, error status: %d\n",
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] net: mctp-i2c: fix duplicate reception of old data

[Sasha Levin]

From: Jian Zhang <zhangjian.3032@bytedance.com>

[ Upstream commit ae4744e173fadd092c43eda4ca92dcb74645225a ]

The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED
events. As a result, i2c read event will trigger repeated reception of
old data, reset rx_pos when a read request is received.

Signed-off-by: Jian Zhang <zhangjian.3032@bytedance.com>
Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com
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 net: mctp-i2c: fix duplicate reception of old data

### 1. Commit Message Analysis

The commit message clearly describes a **bug fix**: the MCTP I2C slave
callback was not handling `I2C_SLAVE_READ_REQUESTED` events, which
caused **duplicate reception of old data** when an I2C read event
occurred. The fix resets `rx_pos` when a read request is received.

Keywords: "fix duplicate reception of old data" — this is an explicit
bug fix.

### 2. Code Change Analysis

The patch makes two changes:

**Change 1: Handle `I2C_SLAVE_READ_REQUESTED` in the switch statement**
```c
case I2C_SLAVE_READ_REQUESTED:
    midev->rx_pos = 0;
    break;
```
This adds handling for a previously unhandled I2C slave event. When a
read request comes in, `rx_pos` is reset to 0, preventing stale data
from being re-processed. Without this, the `rx_pos` would retain its old
value from a previous transaction, and when `I2C_SLAVE_STOP` fires,
`mctp_i2c_recv()` would process stale data in the buffer — resulting in
duplicate/ghost packet reception.

**Change 2: Early return in `mctp_i2c_recv()` when `rx_pos == 0`**
```c
if (midev->rx_pos == 0)
    return 0;
```
This is a defensive guard: if `rx_pos` was reset to 0 (by the new
READ_REQUESTED handler), `mctp_i2c_recv()` should do nothing since
there's no valid write data to process. Without this check, the function
would proceed with invalid state (`rx_pos == 0`), potentially causing
incorrect length calculations or accessing uninitialized buffer data.

### 3. Bug Mechanism

The I2C slave callback handles events during I2C bus transactions. The
MCTP-over-I2C protocol involves the bus master writing MCTP packets.
However, the I2C bus can also generate `I2C_SLAVE_READ_REQUESTED` events
(when the master reads from this slave). Without handling this event:

1. `rx_pos` retains its value from a previous write transaction
2. When `I2C_SLAVE_STOP` fires after the read, `mctp_i2c_recv()`
   processes the stale buffer
3. This causes **duplicate reception of old MCTP packets** — a data
   integrity/correctness bug

### 4. Classification

- **Bug fix**: Yes — fixes incorrect behavior (duplicate packet
  reception)
- **New feature**: No — this handles an existing I2C event that was
  previously ignored
- **Scope**: Very small — adds 5 lines of code across two locations in
  one file

### 5. Stable Criteria Assessment

| Criterion | Assessment |
|-----------|------------|
| Obviously correct and tested | Yes — simple, logical fix; accepted by
net maintainer Jakub Kicinski |
| Fixes a real bug | Yes — duplicate reception of stale MCTP data |
| Important issue | Moderate — data correctness issue in networking
stack |
| Small and contained | Yes — 5 lines added in a single file |
| No new features | Correct — just handles a missing event case |
| Applies cleanly | Likely — small, localized change |

### 6. Risk Assessment

**Risk: Very low**
- The change is minimal and purely additive (no existing code modified)
- Adding a case to a switch statement with a simple assignment is very
  safe
- The early return guard in `mctp_i2c_recv()` is a standard defensive
  check
- Only affects MCTP-over-I2C users — very narrow blast radius

**Benefit: Moderate to High for affected users**
- MCTP (Management Component Transport Protocol) over I2C is used in
  server/BMC management
- Duplicate packet reception causes incorrect behavior in management
  stacks
- Without this fix, any I2C read event corrupts the MCTP receive path

### 7. Dependencies

No dependencies on other commits. The fix is self-contained and modifies
only the existing `mctp_i2c_slave_cb()` function and `mctp_i2c_recv()`
function.

### 8. Conclusion

This is a clean, small, obviously correct bug fix that addresses a real
data corruption/correctness issue (duplicate reception of stale data) in
the MCTP I2C driver. It meets all stable kernel criteria: it's small,
contained, fixes a real bug, introduces no new features, and has very
low regression risk.

**YES**

 drivers/net/mctp/mctp-i2c.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index f782d93f826ef..ecda1cc36391c 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -242,6 +242,9 @@ static int mctp_i2c_slave_cb(struct i2c_client *client,
 		return 0;
 
 	switch (event) {
+	case I2C_SLAVE_READ_REQUESTED:
+		midev->rx_pos = 0;
+		break;
 	case I2C_SLAVE_WRITE_RECEIVED:
 		if (midev->rx_pos < MCTP_I2C_BUFSZ) {
 			midev->rx_buffer[midev->rx_pos] = *val;
@@ -279,6 +282,9 @@ static int mctp_i2c_recv(struct mctp_i2c_dev *midev)
 	size_t recvlen;
 	int status;
 
+	if (midev->rx_pos == 0)
+		return 0;
+
 	/* + 1 for the PEC */
 	if (midev->rx_pos < MCTP_I2C_MINLEN + 1) {
 		ndev->stats.rx_length_errors++;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] net: wwan: mhi: Add network support for Foxconn T99W760

[Sasha Levin]

From: Slark Xiao <slark_xiao@163.com>

[ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ]

T99W760 is designed based on Qualcomm SDX35 chip. It use similar
architecture with SDX72/SDX75 chip. So we need to assign initial
link id for this device to make sure network available.

Signed-off-by: Slark Xiao <slark_xiao@163.com>
Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit adds network support for a new device, the Foxconn T99W760,
which is based on the Qualcomm SDX35 chip. The commit message explains
that this device uses a similar architecture to SDX72/SDX75 and needs an
initial link ID assignment to make networking functional.

### Code Change Analysis

The change is extremely minimal — a single line addition:

```c
strcmp(cntrl->name, "foxconn-t99w760") == 0)
```

This adds the "foxconn-t99w760" device name to the
`mhi_mbim_get_link_mux_id()` function so that it returns
`WDS_BIND_MUX_DATA_PORT_MUX_ID` instead of `0`. This is the same
treatment already given to "foxconn-dw5934e" and "foxconn-t99w640".

### Classification: Device ID / Hardware Enablement

This falls squarely into the **"New Device IDs"** exception category for
stable backports. It's adding support for a specific device to an
existing driver by matching its name and applying the same configuration
that other similar devices already use.

Without this change, users with the Foxconn T99W760 WWAN modem cannot
use networking — the device gets the wrong mux ID (0 instead of
`WDS_BIND_MUX_DATA_PORT_MUX_ID`), making the network interface non-
functional.

### Risk Assessment

- **Scope**: 1 line added, 1 file changed
- **Risk**: Extremely low — the change only affects devices matching the
  exact name "foxconn-t99w760". No other hardware is affected.
- **Pattern**: Follows the exact same pattern as existing devices in the
  same function
- **Complexity**: Trivial string comparison addition

### User Impact

Users with the Foxconn T99W760 WWAN modem (a real shipping hardware
device) cannot use network connectivity without this patch. This is a
real-world hardware enablement fix.

### Stability Assessment

- The driver (`mhi_wwan_mbim.c`) already exists in stable trees
- The function `mhi_mbim_get_link_mux_id()` already exists
- The pattern is identical to existing entries
- Zero risk of regression for any other hardware

### Dependencies

No dependencies on other commits. The change is entirely self-contained.

### Conclusion

This is a textbook device ID addition to an existing driver — one of the
explicitly allowed exception categories for stable backports. It enables
real hardware for real users, is trivially small, has zero regression
risk, and follows an established pattern in the same function.

**YES**

 drivers/net/wwan/mhi_wwan_mbim.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wwan/mhi_wwan_mbim.c b/drivers/net/wwan/mhi_wwan_mbim.c
index f8bc9a39bfa30..1d7e3ad900c12 100644
--- a/drivers/net/wwan/mhi_wwan_mbim.c
+++ b/drivers/net/wwan/mhi_wwan_mbim.c
@@ -98,7 +98,8 @@ static struct mhi_mbim_link *mhi_mbim_get_link_rcu(struct mhi_mbim_context *mbim
 static int mhi_mbim_get_link_mux_id(struct mhi_controller *cntrl)
 {
 	if (strcmp(cntrl->name, "foxconn-dw5934e") == 0 ||
-	    strcmp(cntrl->name, "foxconn-t99w640") == 0)
+	    strcmp(cntrl->name, "foxconn-t99w640") == 0 ||
+	    strcmp(cntrl->name, "foxconn-t99w760") == 0)
 		return WDS_BIND_MUX_DATA_PORT_MUX_ID;
 
 	return 0;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] net/rds: Clear reconnect pending bit

[Sasha Levin]

From: Håkon Bugge <haakon.bugge@oracle.com>

[ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ]

When canceling the reconnect worker, care must be taken to reset the
reconnect-pending bit. If the reconnect worker has not yet been
scheduled before it is canceled, the reconnect-pending bit will stay
on forever.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
Link: https://patch.msgid.link/20260203055723.1085751-6-achender@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:

### 3. BUG MECHANISM — CLEAR AND CRITICAL

Now the full picture is clear:

**The flow:**
1. `rds_queue_reconnect()` at line 138 sets `RDS_RECONNECT_PENDING` and
   queues the delayed work.
2. `rds_connect_worker()` (the worker function) at line 173 clears
   `RDS_RECONNECT_PENDING` when it runs.
3. `rds_conn_path_connect_if_down()` at line 911 uses
   `test_and_set_bit(RDS_RECONNECT_PENDING, ...)` — if the bit is
   already set, it returns without queuing work, trusting that a
   reconnect is already pending.

**The bug:**
In `rds_conn_shutdown()`, `cancel_delayed_work_sync()` cancels the
queued worker. If the worker hadn't started yet, it never runs
`clear_bit(RDS_RECONNECT_PENDING, ...)`. The bit stays set. Then when
`rds_conn_path_connect_if_down()` is later called (e.g., when trying to
send data), `test_and_set_bit` finds the bit already set and skips
queuing — **forever**. The connection can never reconnect.

This is a **permanent connection failure** bug — once triggered, the RDS
connection path is effectively dead until the system is rebooted or the
module is reloaded.

### 4. CLASSIFICATION

- **Bug type:** State corruption / logic bug leading to permanent loss
  of network connectivity
- **Severity:** HIGH — RDS is used in production Oracle RAC clusters and
  RDMA-based environments
- **Trigger:** Race between shutdown and reconnect scheduling —
  realistic in production with network flaps

### 5. SCOPE AND RISK

- **Change size:** 1 functional line (plus 1 blank line) — extremely
  small and surgical
- **Files changed:** 1 file (`net/rds/connection.c`)
- **Risk of regression:** Very low — `clear_bit` is idempotent. If the
  worker already ran and cleared the bit, clearing it again is harmless.
  If the worker didn't run, this is the correct fix.
- **The fix is placed correctly:** After `cancel_delayed_work_sync()`
  guarantees the worker won't run, and before `rds_queue_reconnect()`
  which will set the bit again if needed.

### 6. STABLE KERNEL CRITERIA

- **Obviously correct:** Yes — the logic is straightforward and well-
  explained
- **Fixes a real bug:** Yes — permanent loss of RDS connectivity
- **Important issue:** Yes — affects network reliability for RDS users
  (Oracle, RDMA environments)
- **Small and contained:** Yes — 1 line in 1 file
- **No new features:** Correct — purely a bug fix
- **No new APIs:** Correct

### 7. DEPENDENCY CHECK

This fix is self-contained. It only adds a `clear_bit()` call after an
existing `cancel_delayed_work_sync()` call. The `RDS_RECONNECT_PENDING`
flag and the surrounding code have been in the kernel for a long time.
This should apply cleanly to any stable tree that has the RDS subsystem.

### Conclusion

This is a textbook stable backport candidate: a tiny, obviously correct,
one-line fix for a serious bug (permanent connection failure) in
networking code used in production environments. The fix has zero risk
of regression due to the idempotent nature of `clear_bit`, and the bug
mechanism is clearly explained and verified through code analysis.

**YES**

 net/rds/connection.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rds/connection.c b/net/rds/connection.c
index ad8027e6f54ef..dbfea6fa11260 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -429,6 +429,8 @@ void rds_conn_shutdown(struct rds_conn_path *cp)
 	 * to the conn hash, so we never trigger a reconnect on this
 	 * conn - the reconnect is always triggered by the active peer. */
 	cancel_delayed_work_sync(&cp->cp_conn_w);
+
+	clear_bit(RDS_RECONNECT_PENDING, &cp->cp_flags);
 	rcu_read_lock();
 	if (!hlist_unhashed(&conn->c_hash_node)) {
 		rcu_read_unlock();
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] ipv6: annotate data-races over sysctl.flowlabel_reflect

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 5ade47c974b46eb2a1279185962a0ffa15dc5450 ]

Add missing READ_ONCE() when reading ipv6.sysctl.flowlabel_reflect,
as its value can be changed under us.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260115094141.3124990-6-edumazet@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:

## Analysis of Commit: "ipv6: annotate data-races over
sysctl.flowlabel_reflect"

### 1. COMMIT MESSAGE ANALYSIS

The commit message is clear and direct: it adds missing `READ_ONCE()`
annotations when reading `ipv6.sysctl.flowlabel_reflect` because this
sysctl value can be changed concurrently by another CPU (via the sysctl
write path). The author is Eric Dumazet, a top-tier networking
maintainer known for systematically fixing data races in the networking
stack. Reviewed by Simon Horman, another well-known networking reviewer.

### 2. CODE CHANGE ANALYSIS

The patch modifies exactly 3 locations across 3 files, adding
`READ_ONCE()` around reads of `net->ipv6.sysctl.flowlabel_reflect`:

1. **net/ipv6/af_inet6.c** (`inet6_create`): Socket creation path —
   reads the sysctl to set the `REPFLOW` bit on new IPv6 sockets.

2. **net/ipv6/icmp.c** (`icmpv6_echo_reply`): ICMPv6 echo reply path —
   reads the sysctl to decide whether to reflect the flowlabel in echo
   replies.

3. **net/ipv6/tcp_ipv6.c** (`tcp_v6_send_reset`): TCP reset sending path
   — reads the sysctl to decide whether to reflect the flowlabel in TCP
   resets.

In all three cases, the pattern is identical: a plain read of
`net->ipv6.sysctl.flowlabel_reflect` is wrapped with `READ_ONCE()`. This
is a textbook KCSAN data-race annotation fix.

### 3. BUG CLASSIFICATION

This is a **data race fix**. The sysctl `flowlabel_reflect` can be
modified at any time from another CPU via the sysctl interface. Without
`READ_ONCE()`, the compiler is free to:
- Load the value multiple times (potentially seeing different values
  within a single check)
- Optimize the read in ways that produce undefined behavior under the C
  memory model

This is the exact pattern of KCSAN-detected data races that Eric Dumazet
has been systematically fixing across the networking stack. These are
real data races even if the consequences in practice may be minor (store
tearing or inconsistent reads).

### 4. SCOPE AND RISK ASSESSMENT

- **Size**: Extremely small — 3 locations, each changing a single read
  to `READ_ONCE()`.
- **Risk**: Essentially zero. `READ_ONCE()` is a pure annotation that
  prevents compiler optimization issues. It cannot introduce new bugs.
- **Files touched**: 3 files in net/ipv6/, all well-established code
  paths.
- **Subsystem**: Core IPv6 networking — widely used.

### 5. STABLE KERNEL CRITERIA

- **Obviously correct**: Yes — adding `READ_ONCE()` for a concurrently-
  modified sysctl is a textbook fix.
- **Fixes a real bug**: Yes — data races are real bugs, detectable by
  KCSAN, and can cause undefined behavior.
- **Small and contained**: Yes — minimal change, 3 lines modified.
- **No new features**: Correct — pure bug fix annotation.
- **Tested**: Reviewed by Simon Horman, authored by Eric Dumazet
  (networking co-maintainer).

### 6. USER IMPACT

The `flowlabel_reflect` sysctl affects IPv6 flow label behavior for:
- New socket creation
- ICMPv6 echo replies
- TCP reset packets

While the practical impact of the data race is likely limited (a torn
read of an integer sysctl would just result in a brief wrong decision),
the fix is important for:
- KCSAN cleanliness (preventing false positives that mask real bugs)
- Correctness under the kernel memory model
- Preventing potential compiler-induced bugs on architectures with weak
  memory ordering

### 7. DEPENDENCY CHECK

This commit is self-contained. It only adds `READ_ONCE()` wrappers and
has no dependencies on other commits. The code being modified exists in
all recent stable trees.

### 8. RISK vs BENEFIT

- **Risk**: Near zero. `READ_ONCE()` is a safe, well-understood
  annotation.
- **Benefit**: Fixes real data races in the IPv6 networking path,
  prevents potential compiler-induced misbehavior, enables clean KCSAN
  runs.

This is the type of small, surgical, zero-risk fix that is ideal for
stable backporting. Eric Dumazet's data-race annotation series in
networking has been consistently backported to stable trees.

**YES**

 net/ipv6/af_inet6.c | 4 ++--
 net/ipv6/icmp.c     | 3 ++-
 net/ipv6/tcp_ipv6.c | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index b705751eb73c6..bd29840659f34 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -224,8 +224,8 @@ static int inet6_create(struct net *net, struct socket *sock, int protocol,
 	inet6_set_bit(MC6_LOOP, sk);
 	inet6_set_bit(MC6_ALL, sk);
 	np->pmtudisc	= IPV6_PMTUDISC_WANT;
-	inet6_assign_bit(REPFLOW, sk, net->ipv6.sysctl.flowlabel_reflect &
-				     FLOWLABEL_REFLECT_ESTABLISHED);
+	inet6_assign_bit(REPFLOW, sk, READ_ONCE(net->ipv6.sysctl.flowlabel_reflect) &
+				      FLOWLABEL_REFLECT_ESTABLISHED);
 	sk->sk_ipv6only	= net->ipv6.sysctl.bindv6only;
 	sk->sk_txrehash = READ_ONCE(net->core.sysctl_txrehash);
 
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 9d37e7711bc2b..1a25ecb926951 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -958,7 +958,8 @@ static enum skb_drop_reason icmpv6_echo_reply(struct sk_buff *skb)
 	tmp_hdr.icmp6_type = type;
 
 	memset(&fl6, 0, sizeof(fl6));
-	if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_ICMPV6_ECHO_REPLIES)
+	if (READ_ONCE(net->ipv6.sysctl.flowlabel_reflect) &
+	    FLOWLABEL_REFLECT_ICMPV6_ECHO_REPLIES)
 		fl6.flowlabel = ip6_flowlabel(ipv6_hdr(skb));
 
 	fl6.flowi6_proto = IPPROTO_ICMPV6;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 280fe59785598..4ae664b05fa91 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1085,7 +1085,8 @@ static void tcp_v6_send_reset(const struct sock *sk, struct sk_buff *skb,
 			txhash = inet_twsk(sk)->tw_txhash;
 		}
 	} else {
-		if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_TCP_RESET)
+		if (READ_ONCE(net->ipv6.sysctl.flowlabel_reflect) &
+		    FLOWLABEL_REFLECT_TCP_RESET)
 			label = ip6_flowlabel(ipv6h);
 	}
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] ipv6: exthdrs: annotate data-race over multiple sysctl

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 978b67d28358b0b4eacfa94453d1ad4e09b123ad ]

Following four sysctls can change under us, add missing READ_ONCE().

- ipv6.sysctl.max_dst_opts_len
- ipv6.sysctl.max_dst_opts_cnt
- ipv6.sysctl.max_hbh_opts_len
- ipv6.sysctl.max_hbh_opts_cnt

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260115094141.3124990-8-edumazet@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:

## Analysis of commit: "ipv6: exthdrs: annotate data-race over multiple
sysctl"

### 1. COMMIT MESSAGE ANALYSIS

The commit message is straightforward: it adds `READ_ONCE()` annotations
to four sysctl variables that can be modified concurrently from
userspace while being read in the packet processing path. The author is
Eric Dumazet, a prolific and highly respected networking maintainer at
Google, who frequently contributes data-race annotations and fixes.
Reviewed by Simon Horman, another well-known networking reviewer.

The four sysctls affected:
- `ipv6.sysctl.max_dst_opts_len`
- `ipv6.sysctl.max_dst_opts_cnt`
- `ipv6.sysctl.max_hbh_opts_len`
- `ipv6.sysctl.max_hbh_opts_cnt`

### 2. CODE CHANGE ANALYSIS

The changes are minimal and mechanical - wrapping four sysctl reads with
`READ_ONCE()`:

1. **`ipv6_destopt_rcv()`** (line ~317):
   `net->ipv6.sysctl.max_dst_opts_len` →
   `READ_ONCE(net->ipv6.sysctl.max_dst_opts_len)`
2. **`ipv6_destopt_rcv()`** (line ~326):
   `net->ipv6.sysctl.max_dst_opts_cnt` →
   `READ_ONCE(net->ipv6.sysctl.max_dst_opts_cnt)`
3. **`ipv6_parse_hopopts()`** (line ~1053):
   `net->ipv6.sysctl.max_hbh_opts_len` →
   `READ_ONCE(net->ipv6.sysctl.max_hbh_opts_len)`
4. **`ipv6_parse_hopopts()`** (line ~1056):
   `net->ipv6.sysctl.max_hbh_opts_cnt` →
   `READ_ONCE(net->ipv6.sysctl.max_hbh_opts_cnt)`

These are in the IPv6 extension header packet receive path - hot path
code that processes every incoming IPv6 packet with destination options
or hop-by-hop options. The sysctl values can be changed from userspace
at any time via `/proc/sys/net/ipv6/`, creating a data race.

### 3. BUG MECHANISM

Without `READ_ONCE()`, the compiler is free to:
- Re-read the value multiple times (store tearing), potentially getting
  different values in the same function
- Optimize based on assumptions about the value not changing

This is a real data race detectable by KCSAN (Kernel Concurrency
Sanitizer). While the practical consequences of this particular race are
relatively mild (the comparison values might be slightly stale or torn),
the race is real and in a networking hot path.

### 4. CLASSIFICATION

This is a **data-race fix** — category 3 (Race Conditions) from the
analysis framework. `READ_ONCE()`/`WRITE_ONCE()` annotations are a
common pattern for KCSAN-detected data races and are regularly
backported to stable.

### 5. SCOPE AND RISK ASSESSMENT

- **Lines changed**: ~8 lines across one file
- **Files touched**: 1 (`net/ipv6/exthdrs.c`)
- **Risk**: Extremely low. `READ_ONCE()` is a pure compiler annotation
  that generates identical or near-identical machine code on most
  architectures. It cannot introduce regressions.
- **Subsystem**: IPv6 networking — core infrastructure used by virtually
  all systems

### 6. USER IMPACT

- **Who is affected**: Any system processing IPv6 packets with extension
  headers where sysctl values might be modified concurrently
- **Severity**: Low to medium — the race could theoretically cause
  inconsistent enforcement of the max length/count limits, but more
  importantly it silences KCSAN reports and ensures correct compiler
  behavior
- **In the networking hot path**: These functions process packets, so
  correctness matters

### 7. STABILITY INDICATORS

- **Author**: Eric Dumazet (Google, top networking contributor) — very
  high trust
- **Reviewer**: Simon Horman — respected networking reviewer
- **Pattern**: This is part of a series (patch 8 of a set) of data-race
  annotations, which is a well-established pattern in the networking
  subsystem

### 8. DEPENDENCY CHECK

This commit is self-contained. `READ_ONCE()` is a basic kernel primitive
available in all stable trees. The sysctl variables being annotated have
existed for a long time. No dependencies on other patches.

### 9. VERDICT

This is a small, surgical, zero-risk fix for a real data race in the
IPv6 networking path. It follows the well-established pattern of
`READ_ONCE()` annotations that Eric Dumazet has been systematically
adding across the networking stack. These annotations are routinely
backported to stable trees. The fix is obviously correct, has
essentially zero regression risk, and addresses a real concurrency issue
in core networking code.

**YES**

 net/ipv6/exthdrs.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index a23eb8734e151..54088fa0c09d0 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -314,7 +314,7 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
 	}
 
 	extlen = (skb_transport_header(skb)[1] + 1) << 3;
-	if (extlen > net->ipv6.sysctl.max_dst_opts_len)
+	if (extlen > READ_ONCE(net->ipv6.sysctl.max_dst_opts_len))
 		goto fail_and_free;
 
 	opt->lastopt = opt->dst1 = skb_network_header_len(skb);
@@ -322,7 +322,8 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
 	dstbuf = opt->dst1;
 #endif
 
-	if (ip6_parse_tlv(false, skb, net->ipv6.sysctl.max_dst_opts_cnt)) {
+	if (ip6_parse_tlv(false, skb,
+			  READ_ONCE(net->ipv6.sysctl.max_dst_opts_cnt))) {
 		skb->transport_header += extlen;
 		opt = IP6CB(skb);
 #if IS_ENABLED(CONFIG_IPV6_MIP6)
@@ -1049,11 +1050,12 @@ int ipv6_parse_hopopts(struct sk_buff *skb)
 	}
 
 	extlen = (skb_transport_header(skb)[1] + 1) << 3;
-	if (extlen > net->ipv6.sysctl.max_hbh_opts_len)
+	if (extlen > READ_ONCE(net->ipv6.sysctl.max_hbh_opts_len))
 		goto fail_and_free;
 
 	opt->flags |= IP6SKB_HOPBYHOP;
-	if (ip6_parse_tlv(true, skb, net->ipv6.sysctl.max_hbh_opts_cnt)) {
+	if (ip6_parse_tlv(true, skb,
+			  READ_ONCE(net->ipv6.sysctl.max_hbh_opts_cnt))) {
 		skb->transport_header += extlen;
 		opt = IP6CB(skb);
 		opt->nhoff = sizeof(struct ipv6hdr);
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] octeontx2-af: Workaround SQM/PSE stalls by disabling sticky

[Sasha Levin]

From: Geetha sowjanya <gakula@marvell.com>

[ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ]

NIX SQ manager sticky mode is known to cause stalls when multiple SQs
share an SMQ and transmit concurrently. Additionally, PSE may deadlock
on transitions between sticky and non-sticky transmissions. There is
also a credit drop issue observed when certain condition clocks are
gated.

work around these hardware errata by:
- Disabling SQM sticky operation:
  - Clear TM6 (bit 15)
  - Clear TM11 (bit 14)
- Disabling sticky → non-sticky transition path that can deadlock PSE:
  - Clear TM5 (bit 23)
- Preventing credit drops by keeping the control-flow clock enabled:
  - Set TM9 (bit 21)

These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this
configuration the SQM/PSE maintain forward progress under load without
credit loss, at the cost of disabling sticky optimizations.

Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The register definition exists in the codebase, and the code modifying
it exists. This is a self-contained change that modifies existing
initialization code — no new dependencies needed.

### 8. Summary

**What it fixes**: Hardware errata causing network stalls, PSE deadlock,
and credit drops on OcteonTX2 hardware under concurrent transmission
load.

**Why it matters for stable**: Users running OcteonTX2 hardware on
stable kernels will experience these hardware bugs (stalls, deadlocks,
packet loss) without this workaround. These are reliability/availability
issues for networking hardware commonly used in production.

**Meets stable rules**:
- Obviously correct: Simple register bit manipulation with clear
  documentation
- Fixes real bugs: Hardware stalls, deadlocks, and credit drops
- Small and contained: Single file, ~10 lines of actual change
- No new features: Hardware errata workaround only
- Reviewed by networking maintainers

**Risk**: Minimal. Only affects OcteonTX2 hardware initialization. The
trade-off (disabling sticky optimizations) is explicitly acknowledged
and accepted.

**YES**

 drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
index 2f485a930edd1..49f7ff5eddfc8 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
@@ -4938,12 +4938,18 @@ static int rvu_nix_block_init(struct rvu *rvu, struct nix_hw *nix_hw)
 	/* Set chan/link to backpressure TL3 instead of TL2 */
 	rvu_write64(rvu, blkaddr, NIX_AF_PSE_CHANNEL_LEVEL, 0x01);
 
-	/* Disable SQ manager's sticky mode operation (set TM6 = 0)
+	/* Disable SQ manager's sticky mode operation (set TM6 = 0, TM11 = 0)
 	 * This sticky mode is known to cause SQ stalls when multiple
-	 * SQs are mapped to same SMQ and transmitting pkts at a time.
+	 * SQs are mapped to same SMQ and transmitting pkts simultaneously.
+	 * NIX PSE may deadlock when there are any sticky to non-sticky
+	 * transmission. Hence disable it (TM5 = 0).
 	 */
 	cfg = rvu_read64(rvu, blkaddr, NIX_AF_SQM_DBG_CTL_STATUS);
-	cfg &= ~BIT_ULL(15);
+	cfg &= ~(BIT_ULL(15) | BIT_ULL(14) | BIT_ULL(23));
+	/* NIX may drop credits when condition clocks are turned off.
+	 * Hence enable control flow clk (set TM9 = 1).
+	 */
+	cfg |= BIT_ULL(21);
 	rvu_write64(rvu, blkaddr, NIX_AF_SQM_DBG_CTL_STATUS, cfg);
 
 	ltdefs = rvu->kpu.lt_def;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] vmw_vsock: bypass false-positive Wnonnull warning with gcc-16

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ]

The gcc-16.0.1 snapshot produces a false-positive warning that turns
into a build failure with CONFIG_WERROR:

In file included from arch/x86/include/asm/string.h:6,
                 from net/vmw_vsock/vmci_transport.c:10:
In function 'vmci_transport_packet_init',
    inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2:
arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull]
  150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy'
  164 |                 memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
      |                 ^~~~~~
arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy'
net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy'
  164 |                 memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
      |                 ^~~~~~

This seems relatively harmless, and it so far the only instance of this
warning I have found. The __vmci_transport_send_control_pkt function
is called either with wait=NULL or with one of the type values that
pass 'wait' into memcpy() here, but not from the same caller.

Replacing the memcpy with a struct assignment is otherwise the same
but avoids the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Bryan Tan <bryan-bt.tan@broadcom.com>
Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@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

### Commit Message Analysis

This commit addresses a **false-positive compiler warning** with
gcc-16.0.1 that becomes a **build failure** when `CONFIG_WERROR` is
enabled. The fix replaces a `memcpy()` call with a direct struct
assignment, which is semantically equivalent but avoids triggering the
`-Wnonnull` warning.

### Code Change Analysis

The change is extremely minimal — a single line change:
```c
- memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
+ pkt->u.wait = *wait;
```

This is a purely mechanical transformation. A struct assignment and a
`memcpy` of the same struct size produce identical behavior. The
compiler generates equivalent code. The only difference is that the
struct assignment form doesn't trigger gcc-16's `-Wnonnull` analysis,
which was producing a false positive by analyzing the `memcpy` call
without considering that the `wait` parameter is only NULL for packet
types that don't reach this code path.

### Classification: Build Fix

This is a **build fix** — one of the explicitly allowed categories for
stable backports. With `CONFIG_WERROR` enabled (which is the default in
many distribution kernel configs and increasingly common), this warning
becomes a hard build error. Users building with gcc-16 and
`CONFIG_WERROR` would be unable to compile the kernel.

### Risk Assessment

- **Risk: Extremely low.** The change is a 1:1 semantic equivalent.
  `pkt->u.wait = *wait` does exactly what `memcpy(&pkt->u.wait, wait,
  sizeof(pkt->u.wait))` does — it copies the struct contents. There is
  zero behavioral change.
- **Scope: One line in one file.** Maximally contained.
- **Testing: Well-reviewed.** Has three `Reviewed-by` tags from relevant
  maintainers (Bobby Eshleman, Stefano Garzarella, Bryan Tan).

### Dependency Check

This commit has no dependencies on other patches. The code being
modified (`vmci_transport_packet_init`) has existed for a long time in
the stable trees.

### User Impact

- Users building the kernel with gcc-16 and `CONFIG_WERROR` will hit a
  build failure without this fix.
- gcc-16 is a snapshot/development compiler now, but will become the
  standard gcc version in distributions. As distributions adopt gcc-16,
  this will become a real issue for stable kernel users.
- Build fixes are critical for the usability of stable kernels.

### Stability Assessment

- The change is trivially correct — struct assignment and memcpy of a
  struct are equivalent.
- Multiple experienced reviewers have confirmed correctness.
- Zero risk of runtime regression.

### Conclusion

This is a textbook stable backport candidate: a minimal, zero-risk build
fix that prevents compilation failure with newer compiler versions. It
falls squarely into the "build fixes that prevent compilation" exception
category. The change is semantically identical to the original code and
has been well-reviewed.

**YES**

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

diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 7eccd6708d664..aca3132689cf1 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -161,7 +161,7 @@ vmci_transport_packet_init(struct vmci_transport_packet *pkt,
 
 	case VMCI_TRANSPORT_PACKET_TYPE_WAITING_READ:
 	case VMCI_TRANSPORT_PACKET_TYPE_WAITING_WRITE:
-		memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
+		pkt->u.wait = *wait;
 		break;
 
 	case VMCI_TRANSPORT_PACKET_TYPE_REQUEST2:
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}()

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 03e9d91dd64e2f5ea632df5d59568d91757efc4d ]

Add missing READ_ONCE() when reading sysctl values.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260115094141.3124990-5-edumazet@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:

## Analysis of ipv6: annotate data-races in
ip6_multipath_hash_{policy,fields}()

### 1. COMMIT MESSAGE ANALYSIS

The commit is authored by Eric Dumazet, a well-known and prolific
networking subsystem maintainer at Google. The subject explicitly says
"annotate data-races," which is a common pattern for KCSAN (Kernel
Concurrency Sanitizer) data race fixes. The commit adds `READ_ONCE()`
annotations when reading sysctl values that can be concurrently modified
by userspace.

Reviewed by Simon Horman (another senior networking maintainer) and
committed by Jakub Kicinski (networking subsystem maintainer). This is a
high-trust chain.

### 2. CODE CHANGE ANALYSIS

The change is extremely minimal - exactly 2 lines changed in a single
header file:

```c
// Before:
return net->ipv6.sysctl.multipath_hash_policy;
return net->ipv6.sysctl.multipath_hash_fields;

// After:
return READ_ONCE(net->ipv6.sysctl.multipath_hash_policy);
return READ_ONCE(net->ipv6.sysctl.multipath_hash_fields);
```

**What's happening:** These two inline functions read sysctl values
(`multipath_hash_policy` and `multipath_hash_fields`) from the network
namespace's sysctl structure. These values can be modified at any time
by userspace through `/proc/sys/net/ipv6/...`. Without `READ_ONCE()`,
the compiler is free to:
- Load the value multiple times (store-tearing)
- Optimize/reorder the read in unexpected ways
- Cause inconsistent behavior if the value changes mid-function

This is a classic data race: a sysctl writer (from userspace) and a
packet processing reader (in softirq/RCU context) access the same memory
without synchronization. `READ_ONCE()` prevents compiler-induced issues
and documents the intentional lock-free access pattern.

### 3. CLASSIFICATION

This is a **data race fix**, falling under category #3 (RACE CONDITIONS)
from the bug patterns. While the practical consequences of this
particular race may be minor (the worst case is likely reading a
partially-updated or stale value for hash policy/fields), the fix is:

- Standard practice in the networking stack (Eric Dumazet has done
  hundreds of these)
- Prevents KCSAN warnings that indicate real concurrent access
- Prevents potential compiler optimizations that could cause subtle bugs
- Part of the kernel's correctness guarantees

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 2 (extremely minimal)
- **Files touched:** 1 header file
- **Complexity:** Trivial - `READ_ONCE()` is a well-understood macro
- **Risk of regression:** Essentially zero. `READ_ONCE()` is a volatile
  read barrier that cannot change functional behavior. It only
  constrains the compiler.
- **Subsystem:** IPv6 networking (core, affects everyone using IPv6
  multipath routing)

### 5. USER IMPACT

- Affects anyone using IPv6 multipath routing with hash policy or hash
  fields sysctls
- The data race could theoretically cause incorrect hash computation
  leading to suboptimal load balancing, though the practical impact is
  low
- KCSAN reports these as warnings, which clutters logs and may mask
  other real issues

### 6. STABILITY INDICATORS

- Reviewed by Simon Horman
- Author is Eric Dumazet (top networking contributor)
- Committed by Jakub Kicinski (networking maintainer)
- This is a well-established pattern - dozens of identical `READ_ONCE()`
  annotation patches have been backported to stable

### 7. DEPENDENCY CHECK

No dependencies. `READ_ONCE()` has existed in the kernel for many years.
The functions `ip6_multipath_hash_policy()` and
`ip6_multipath_hash_fields()` exist in all recent stable trees. This
patch applies trivially.

### Decision

This is a textbook data race annotation fix: 2-line change, zero
regression risk, fixes a real (if minor) concurrency bug, authored and
reviewed by top networking maintainers. These
`READ_ONCE()`/`WRITE_ONCE()` annotations for sysctl values are routinely
backported to stable trees. The fix is small, surgical, and meets all
stable kernel criteria.

**YES**

 include/net/ipv6.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 74fbf1ad8065a..a0407b9f510ad 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -1010,11 +1010,11 @@ static inline int ip6_default_np_autolabel(struct net *net)
 #if IS_ENABLED(CONFIG_IPV6)
 static inline int ip6_multipath_hash_policy(const struct net *net)
 {
-	return net->ipv6.sysctl.multipath_hash_policy;
+	return READ_ONCE(net->ipv6.sysctl.multipath_hash_policy);
 }
 static inline u32 ip6_multipath_hash_fields(const struct net *net)
 {
-	return net->ipv6.sysctl.multipath_hash_fields;
+	return READ_ONCE(net->ipv6.sysctl.multipath_hash_fields);
 }
 #else
 static inline int ip6_multipath_hash_policy(const struct net *net)
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.6] ipv4: igmp: annotate data-races around idev->mr_maxdelay

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit e4faaf65a75f650ac4366ddff5dabb826029ca5a ]

idev->mr_maxdelay is read and written locklessly,
add READ_ONCE()/WRITE_ONCE() annotations.

While we are at it, make this field an u32.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@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:

## Analysis of commit: "ipv4: igmp: annotate data-races around
idev->mr_maxdelay"

### 1. COMMIT MESSAGE ANALYSIS

The commit message is straightforward: it adds READ_ONCE()/WRITE_ONCE()
annotations to `idev->mr_maxdelay` because the field is read and written
locklessly (i.e., without holding a lock that protects both the reader
and writer). Additionally, the field type is changed from `unsigned
long` to `u32`.

**Author**: Eric Dumazet — a highly prolific and respected networking
developer at Google, known for data-race annotation work across the
networking stack.

**Reviewed-by**: David Ahern — another senior networking developer.

### 2. CODE CHANGE ANALYSIS

The changes are minimal and contained:

**In `include/linux/inetdevice.h`:**
- `mr_maxdelay` field type changed from `unsigned long` to `u32`
- Field repositioned in the struct (moved after `mr_gq_running` which is
  `unsigned char`, before `mr_ifc_count` which is `u32`) — this is
  likely for better packing/alignment

**In `net/ipv4/igmp.c`:**
- **Line ~230 (igmp_gq_start_timer)**: `in_dev->mr_maxdelay` →
  `READ_ONCE(in_dev->mr_maxdelay)` — the reader side
- **Line ~1012 (igmp_heard_query)**: `in_dev->mr_maxdelay = max_delay` →
  `WRITE_ONCE(in_dev->mr_maxdelay, max_delay)` — the writer side

### 3. DATA RACE ANALYSIS

Let me examine the concurrency situation:

- **Writer**: `igmp_heard_query()` writes `mr_maxdelay` when processing
  an incoming IGMPv3 query. This runs in softirq/BH context when
  receiving network packets.
- **Reader**: `igmp_gq_start_timer()` reads `mr_maxdelay` to calculate a
  random timer delay. This is called from `igmp_heard_query()` itself,
  but also potentially from other contexts.

The key question: can the read and write happen concurrently? Looking at
the code, `igmp_heard_query()` writes `mr_maxdelay` and then calls
`igmp_gq_start_timer()` which reads it. However, on different CPUs
processing different network packets, one CPU could be writing while
another reads. Without proper annotations, the compiler could optimize
these accesses in ways that cause tearing or stale reads.

This is a real KCSAN-detectable data race. While the consequences may
not be catastrophic (the value is used for a random timer delay), it is
technically undefined behavior in the C memory model, and on
architectures where `unsigned long` is 64-bit but atomicity is only
guaranteed for 32-bit, there could be torn reads producing garbage
values that get passed to `get_random_u32_below()`.

### 4. TYPE CHANGE: unsigned long → u32

The change from `unsigned long` to `u32` is notable:
- `max_delay` in `igmp_heard_query()` is computed as
  `IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE)` — the MRC field is from
  a network packet and is bounded, so the value fits in u32.
- `get_random_u32_below()` takes a `u32` argument, so this makes the
  types consistent.
- On 64-bit systems, this also ensures atomic read/write since u32
  accesses are atomic on all Linux-supported architectures, which
  complements the READ_ONCE/WRITE_ONCE annotations.

### 5. RISK ASSESSMENT

**Risk**: Very low.
- The READ_ONCE/WRITE_ONCE annotations are purely compiler directives
  that don't change runtime behavior on most architectures
- The type change from `unsigned long` to `u32` is safe because the
  values stored are always small (timer delays in jiffies, derived from
  IGMP protocol fields)
- The struct field reordering doesn't affect functionality
- Only 2 files changed, only 3 lines of actual code logic changed

**Benefit**: Fixes a data race that could theoretically cause:
- Torn reads on 32-bit architectures (if `unsigned long` were involved
  in non-atomic access — though on 32-bit it's 32-bit anyway)
- Compiler-induced issues where the compiler might reload or optimize
  the value in unexpected ways
- Silences KCSAN warnings, which is important for finding real races

### 6. STABLE SUITABILITY

**Meets stable criteria?**
- **Obviously correct**: Yes — this is a textbook data-race annotation
  pattern from a top networking developer, reviewed by another expert
- **Fixes a real bug**: Yes — data races are real bugs (KCSAN reports
  them), even if the consequences are subtle
- **Small and contained**: Yes — minimal changes across 2 files
- **No new features**: Correct — purely a bug fix
- **No new APIs**: Correct

**Concerns:**
- The type change (`unsigned long` → `u32`) and struct field reordering
  are slightly beyond "pure annotation" and could theoretically conflict
  with other patches. However, the type change is necessary for
  correctness (ensuring atomicity on all architectures).
- The struct layout change might cause minor backport conflicts if other
  fields were added/modified in stable trees.

### 7. PRECEDENT

Eric Dumazet has authored hundreds of similar READ_ONCE/WRITE_ONCE
annotation patches in the networking stack, and many of them have been
backported to stable. These are considered important for correctness and
for enabling KCSAN to find real bugs by eliminating false positives.

### 8. CONCLUSION

This is a small, well-reviewed fix for a real data race in the IPv4 IGMP
code path. The IGMP code handles multicast group membership and is used
on any system with multicast networking. The fix is from a trusted
author, reviewed by a trusted reviewer, and follows established
patterns. The type change is safe and actually improves correctness. The
risk of regression is negligible.

**YES**

 include/linux/inetdevice.h | 2 +-
 net/ipv4/igmp.c            | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 5730ba6b1cfaf..dccbeb25f7014 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -38,11 +38,11 @@ struct in_device {
 	struct ip_mc_list	*mc_tomb;
 	unsigned long		mr_v1_seen;
 	unsigned long		mr_v2_seen;
-	unsigned long		mr_maxdelay;
 	unsigned long		mr_qi;		/* Query Interval */
 	unsigned long		mr_qri;		/* Query Response Interval */
 	unsigned char		mr_qrv;		/* Query Robustness Variable */
 	unsigned char		mr_gq_running;
+	u32			mr_maxdelay;
 	u32			mr_ifc_count;
 	struct timer_list	mr_gq_timer;	/* general query timer */
 	struct timer_list	mr_ifc_timer;	/* interface change timer */
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 7182f1419c2a4..0adc993c211d7 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -227,7 +227,7 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
 
 static void igmp_gq_start_timer(struct in_device *in_dev)
 {
-	int tv = get_random_u32_below(in_dev->mr_maxdelay);
+	int tv = get_random_u32_below(READ_ONCE(in_dev->mr_maxdelay));
 	unsigned long exp = jiffies + tv + 2;
 
 	if (in_dev->mr_gq_running &&
@@ -1009,7 +1009,7 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
 		max_delay = IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE);
 		if (!max_delay)
 			max_delay = 1;	/* can't mod w/ 0 */
-		in_dev->mr_maxdelay = max_delay;
+		WRITE_ONCE(in_dev->mr_maxdelay, max_delay);
 
 		/* RFC3376, 4.1.6. QRV and 4.1.7. QQIC, when the most recently
 		 * received value was zero, use the default or statically
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] net/rds: No shortcut out of RDS_CONN_ERROR

[Sasha Levin]

From: Gerd Rausch <gerd.rausch@oracle.com>

[ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ]

RDS connections carry a state "rds_conn_path::cp_state"
and transitions from one state to another and are conditional
upon an expected state: "rds_conn_path_transition."

There is one exception to this conditionality, which is
"RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"
regardless of what state the condition is currently in.

But as soon as a connection enters state "RDS_CONN_ERROR",
the connection handling code expects it to go through the
shutdown-path.

The RDS/TCP multipath changes added a shortcut out of
"RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"
via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").

A subsequent "rds_tcp_reset_callbacks" can then transition
the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.

That'll trip up "rds_conn_init_shutdown", which was
never adjusted to handle "RDS_CONN_RESETTING" and subsequently
drops the connection with the dreaded "DR_INV_CONN_STATE",
which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.

So we do two things here:

a) Don't shortcut "RDS_CONN_ERROR", but take the longer
   path through the shutdown code.

b) Add "RDS_CONN_RESETTING" to the expected states in
  "rds_conn_init_shutdown" so that we won't error out
  and get stuck, if we ever hit weird state transitions
  like this again."

Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
Link: https://patch.msgid.link/20260122055213.83608-2-achender@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 net/rds: No shortcut out of RDS_CONN_ERROR

### 1. COMMIT MESSAGE ANALYSIS

The commit message is detailed and clearly describes a **state machine
bug** in the RDS (Reliable Datagram Sockets) TCP multipath code:

- A connection in `RDS_CONN_ERROR` state was being shortcut directly to
  `RDS_CONN_CONNECTING` via `rds_tcp_accept_one_path`, bypassing the
  required shutdown path.
- This leads to a subsequent transition to `RDS_CONN_RESETTING` with a
  shutdown worker queued.
- `rds_conn_init_shutdown` was never adjusted to handle
  `RDS_CONN_RESETTING`, causing it to drop the connection with
  `DR_INV_CONN_STATE`.
- This leaves `RDS_SHUTDOWN_WORK_QUEUED` set forever, effectively
  **permanently breaking the connection**.

The description of "leaves RDS_SHUTDOWN_WORK_QUEUED on forever" is a
serious consequence — it means the RDS connection gets permanently
stuck, which is essentially a hang/denial of service for RDS users.

### 2. CODE CHANGE ANALYSIS

The fix has two parts:

**Part A: `net/rds/tcp_listen.c` — Remove the shortcut from
RDS_CONN_ERROR**

```c
- if (rds_conn_path_transition(cp, RDS_CONN_DOWN,
- RDS_CONN_CONNECTING) ||
- rds_conn_path_transition(cp, RDS_CONN_ERROR,
- RDS_CONN_CONNECTING)) {
+ if (rds_conn_path_transition(cp, RDS_CONN_DOWN,
+                              RDS_CONN_CONNECTING)) {
```

This removes the problematic shortcut that allowed `RDS_CONN_ERROR` →
`RDS_CONN_CONNECTING` directly, which bypassed the shutdown path. The
comment explaining this shortcut behavior is also removed.

**Part B: `net/rds/connection.c` — Handle RDS_CONN_RESETTING in
shutdown**

```c
 if (!rds_conn_path_transition(cp, RDS_CONN_UP,
                               RDS_CONN_DISCONNECTING) &&
     !rds_conn_path_transition(cp, RDS_CONN_ERROR,
+                              RDS_CONN_DISCONNECTING) &&
+    !rds_conn_path_transition(cp, RDS_CONN_RESETTING,
                               RDS_CONN_DISCONNECTING)) {
```

This adds `RDS_CONN_RESETTING` as an acceptable state to transition from
during shutdown, making the shutdown code more robust against unexpected
state transitions.

### 3. BUG CLASSIFICATION

This is a **state machine bug** that leads to:
- **Connection hang**: RDS connections get permanently stuck with
  `RDS_SHUTDOWN_WORK_QUEUED` set forever
- **Denial of service**: Users of RDS (common in Oracle database
  clusters) lose connectivity
- This is effectively a **deadlock/livelock** in the connection state
  machine

### 4. SCOPE AND RISK ASSESSMENT

- **Files changed**: 2 files
- **Lines changed**: Very small — removing 3 lines from one function,
  adding 2 lines to another
- **Subsystem**: net/rds (RDS networking, widely used in Oracle
  environments)
- **Risk**: LOW — The changes are surgical and well-contained:
  - Part A removes a transition that was causing the bug (conservative
    change)
  - Part B adds defensive handling for an additional state in the
    shutdown path (safe addition)
- **Could this break something?**: Removing the shortcut means
  connections in ERROR state will take the longer path through shutdown.
  This is the correct/expected behavior and should not cause
  regressions.

### 5. USER IMPACT

RDS is used extensively in:
- Oracle RAC (Real Application Clusters) database environments
- High-availability enterprise systems
- Oracle Cloud Infrastructure

A permanently stuck connection is a serious production issue for these
users. The bug is in the multipath code path, which is actively used in
modern RDS deployments.

### 6. STABLE KERNEL CRITERIA

- **Obviously correct**: Yes — the commit message explains the problem
  clearly, and the fix is straightforward state machine correction
- **Fixes a real bug**: Yes — connections getting permanently stuck is a
  real, user-impacting bug
- **Important issue**: Yes — connection hangs in enterprise networking
  code
- **Small and contained**: Yes — minimal changes to 2 files in the same
  subsystem
- **No new features**: Correct — this only fixes state machine
  transitions
- **Tested**: The commit comes from Oracle developers (Gerd Rausch,
  Allison Henderson) who maintain RDS and was accepted by the net
  maintainer (Jakub Kicinski)

### 7. DEPENDENCY CHECK

The fix is self-contained. It modifies existing state transition logic
that has been present since the multipath changes were added. The
`RDS_CONN_RESETTING` state and the relevant functions all exist in
stable kernels that have RDS TCP multipath support.

### Summary

This is a clear bug fix for a state machine issue in RDS TCP multipath
that causes connections to get permanently stuck. The fix is small,
surgical, well-understood, and comes from the RDS subsystem maintainers
at Oracle. It fixes a real production issue (permanent connection hang)
with minimal risk of regression. It meets all stable kernel criteria.

**YES**

 net/rds/connection.c | 2 ++
 net/rds/tcp_listen.c | 5 -----
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/rds/connection.c b/net/rds/connection.c
index 68bc88cce84ec..ad8027e6f54ef 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -382,6 +382,8 @@ void rds_conn_shutdown(struct rds_conn_path *cp)
 		if (!rds_conn_path_transition(cp, RDS_CONN_UP,
 					      RDS_CONN_DISCONNECTING) &&
 		    !rds_conn_path_transition(cp, RDS_CONN_ERROR,
+					      RDS_CONN_DISCONNECTING) &&
+		    !rds_conn_path_transition(cp, RDS_CONN_RESETTING,
 					      RDS_CONN_DISCONNECTING)) {
 			rds_conn_path_error(cp,
 					    "shutdown called in state %d\n",
diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c
index 820d3e20de195..27b6107ddc28d 100644
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -59,9 +59,6 @@ void rds_tcp_keepalive(struct socket *sock)
  * socket and force a reconneect from smaller -> larger ip addr. The reason
  * we special case cp_index 0 is to allow the rds probe ping itself to itself
  * get through efficiently.
- * Since reconnects are only initiated from the node with the numerically
- * smaller ip address, we recycle conns in RDS_CONN_ERROR on the passive side
- * by moving them to CONNECTING in this function.
  */
 static
 struct rds_tcp_connection *rds_tcp_accept_one_path(struct rds_connection *conn)
@@ -86,8 +83,6 @@ struct rds_tcp_connection *rds_tcp_accept_one_path(struct rds_connection *conn)
 		struct rds_conn_path *cp = &conn->c_path[i];
 
 		if (rds_conn_path_transition(cp, RDS_CONN_DOWN,
-					     RDS_CONN_CONNECTING) ||
-		    rds_conn_path_transition(cp, RDS_CONN_ERROR,
 					     RDS_CONN_CONNECTING)) {
 			return cp->cp_transport_data;
 		}
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] ipv6: annotate data-races in net/ipv6/route.c

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit f062e8e25102324364aada61b8283356235bc3c1 ]

sysctls are read while their values can change,
add READ_ONCE() annotations.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260115094141.3124990-9-edumazet@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:

## Analysis: ipv6: annotate data-races in net/ipv6/route.c

### Commit Message Analysis

The commit message is straightforward: it adds `READ_ONCE()` annotations
to sysctl reads in the IPv6 routing code where values can be
concurrently modified. This is authored by Eric Dumazet, a prolific
networking maintainer at Google who regularly submits KCSAN data-race
annotation patches. Reviewed by Simon Horman.

### Code Change Analysis

The patch adds `READ_ONCE()` annotations to the following sysctl fields
read from `net->ipv6.sysctl.*`:

1. **`ip6_rt_mtu_expires`** in `rt6_do_update_pmtu()` — MTU expiration
   timer
2. **`ip6_rt_min_advmss`** in `ip6_default_advmss()` — minimum
   advertised MSS (also refactored from if/assign to `max_t()`)
3. **`ip6_rt_gc_min_interval`** in `ip6_dst_gc()` — GC minimum interval
4. **`ip6_rt_gc_elasticity`** in `ip6_dst_gc()` — GC elasticity
5. **`ip6_rt_gc_timeout`** in `ip6_dst_gc()` — GC timeout
6. **`ip6_rt_last_gc`** in `ip6_dst_gc()` — last GC timestamp (this is
   `READ_ONCE` on a non-sysctl field, but still a concurrent access)
7. **`skip_notify_on_dev_down`** in `rt6_sync_down_dev()` — device down
   notification skip flag
8. **`fib_notify_on_flag_change`** in `fib6_info_hw_flags_set()` — FIB
   notification flag (read into local variable to ensure consistent use)
9. **`flush_delay`** in `ipv6_sysctl_rtcache_flush()` — route cache
   flush delay

### Bug Classification

These are **KCSAN data-race fixes**. The sysctl values are written from
userspace via `/proc/sys/net/ipv6/...` while being read concurrently
from network processing paths. Without `READ_ONCE()`:

- The compiler is free to reload the value multiple times, potentially
  getting different values within the same function
- This can cause inconsistent behavior (e.g., in
  `fib6_info_hw_flags_set()` where `fib_notify_on_flag_change` is
  checked twice — once for `== 2` and once for `!= 0` — a torn read
  could skip both checks or trigger unexpected paths)
- KCSAN will report these as data races

### Specific Risk Assessment

The most interesting change is in `fib6_info_hw_flags_set()` where the
sysctl value is read once into a local variable and then used for both
comparisons. Without this, the value could change between the `== 2`
check and the `!= 0` check, leading to potentially skipping the
notification when it shouldn't be skipped (or vice versa). This is a
real logic consistency bug, not just a theoretical annotation.

The `ip6_dst_gc()` changes protect GC parameters that could be torn-
read, potentially affecting garbage collection timing and behavior.

### Scope and Risk

- **Files changed**: 1 (net/ipv6/route.c)
- **Lines changed**: ~20 lines, all mechanical `READ_ONCE()` additions
- **Risk**: Very low — `READ_ONCE()` is a compiler barrier that prevents
  optimization-based re-reading. It doesn't change any logic or locking.
  The `max_t()` refactor in `ip6_default_advmss()` is functionally
  equivalent to the original if/assign pattern.
- **Dependencies**: None — `READ_ONCE()` is a basic kernel macro
  available in all stable trees.

### Stable Criteria Assessment

1. **Obviously correct and tested**: Yes — mechanical `READ_ONCE()`
   additions, reviewed by Simon Horman
2. **Fixes a real bug**: Yes — data races detected by KCSAN; the
   `fib_notify_on_flag_change` double-read is a real logic bug
3. **Important issue**: Medium — data races in networking code can cause
   subtle misbehavior. KCSAN annotations are routinely backported
4. **Small and contained**: Yes — single file, ~20 lines of mechanical
   changes
5. **No new features**: Correct — pure annotation/fix
6. **Applies cleanly**: Should apply cleanly to recent stable trees

### Precedent

Eric Dumazet's `READ_ONCE()`/`WRITE_ONCE()` annotation patches for
networking sysctls are regularly backported to stable trees. This is
part of an ongoing effort to make the networking stack KCSAN-clean, and
these patches have a strong track record of being safe and beneficial.

### Conclusion

This is a low-risk, well-understood data-race fix in core IPv6 routing
code. The `fib6_info_hw_flags_set()` fix addresses a real logic
consistency bug where a sysctl value could change between two reads
within the same function. The remaining annotations prevent compiler-
induced re-reads of concurrently modifiable values. This type of patch
is routinely and safely backported to stable.

**YES**

 net/ipv6/route.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index e3a260a5564ba..cd229974b7974 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2895,7 +2895,7 @@ static void rt6_do_update_pmtu(struct rt6_info *rt, u32 mtu)
 
 	dst_metric_set(&rt->dst, RTAX_MTU, mtu);
 	rt->rt6i_flags |= RTF_MODIFIED;
-	rt6_update_expires(rt, net->ipv6.sysctl.ip6_rt_mtu_expires);
+	rt6_update_expires(rt, READ_ONCE(net->ipv6.sysctl.ip6_rt_mtu_expires));
 }
 
 static bool rt6_cache_allowed_for_pmtu(const struct rt6_info *rt)
@@ -3256,8 +3256,8 @@ static unsigned int ip6_default_advmss(const struct dst_entry *dst)
 	rcu_read_lock();
 
 	net = dst_dev_net_rcu(dst);
-	if (mtu < net->ipv6.sysctl.ip6_rt_min_advmss)
-		mtu = net->ipv6.sysctl.ip6_rt_min_advmss;
+	mtu = max_t(unsigned int, mtu,
+		    READ_ONCE(net->ipv6.sysctl.ip6_rt_min_advmss));
 
 	rcu_read_unlock();
 
@@ -3359,10 +3359,10 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
 static void ip6_dst_gc(struct dst_ops *ops)
 {
 	struct net *net = container_of(ops, struct net, ipv6.ip6_dst_ops);
-	int rt_min_interval = net->ipv6.sysctl.ip6_rt_gc_min_interval;
-	int rt_elasticity = net->ipv6.sysctl.ip6_rt_gc_elasticity;
-	int rt_gc_timeout = net->ipv6.sysctl.ip6_rt_gc_timeout;
-	unsigned long rt_last_gc = net->ipv6.ip6_rt_last_gc;
+	int rt_min_interval = READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_min_interval);
+	int rt_elasticity = READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_elasticity);
+	int rt_gc_timeout = READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_timeout);
+	unsigned long rt_last_gc = READ_ONCE(net->ipv6.ip6_rt_last_gc);
 	unsigned int val;
 	int entries;
 
@@ -5008,7 +5008,7 @@ void rt6_sync_down_dev(struct net_device *dev, unsigned long event)
 	};
 	struct net *net = dev_net(dev);
 
-	if (net->ipv6.sysctl.skip_notify_on_dev_down)
+	if (READ_ONCE(net->ipv6.sysctl.skip_notify_on_dev_down))
 		fib6_clean_all_skip_notify(net, fib6_ifdown, &arg);
 	else
 		fib6_clean_all(net, fib6_ifdown, &arg);
@@ -6408,6 +6408,7 @@ void fib6_rt_update(struct net *net, struct fib6_info *rt,
 void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
 			    bool offload, bool trap, bool offload_failed)
 {
+	u8 fib_notify_on_flag_change;
 	struct sk_buff *skb;
 	int err;
 
@@ -6419,8 +6420,9 @@ void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
 	WRITE_ONCE(f6i->offload, offload);
 	WRITE_ONCE(f6i->trap, trap);
 
+	fib_notify_on_flag_change = READ_ONCE(net->ipv6.sysctl.fib_notify_on_flag_change);
 	/* 2 means send notifications only if offload_failed was changed. */
-	if (net->ipv6.sysctl.fib_notify_on_flag_change == 2 &&
+	if (fib_notify_on_flag_change == 2 &&
 	    READ_ONCE(f6i->offload_failed) == offload_failed)
 		return;
 
@@ -6432,7 +6434,7 @@ void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
 		 */
 		return;
 
-	if (!net->ipv6.sysctl.fib_notify_on_flag_change)
+	if (!fib_notify_on_flag_change)
 		return;
 
 	skb = nlmsg_new(rt6_nlmsg_size(f6i), GFP_KERNEL);
@@ -6529,7 +6531,7 @@ static int ipv6_sysctl_rtcache_flush(const struct ctl_table *ctl, int write,
 		return ret;
 
 	net = (struct net *)ctl->extra1;
-	delay = net->ipv6.sysctl.flush_delay;
+	delay = READ_ONCE(net->ipv6.sysctl.flush_delay);
 	fib6_run_gc(delay <= 0 ? 0 : (unsigned long)delay, net, delay > 0);
 	return 0;
 }
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] bnxt_en: Allow ntuple filters for drops

[Sasha Levin]

From: Joe Damato <joe@dama.to>

[ Upstream commit 61cef6454cfbb9fcdbe41401fb53895f86603081 ]

It appears that in commit 7efd79c0e689 ("bnxt_en: Add drop action
support for ntuple"), bnxt gained support for ntuple filters for packet
drops.

However, support for this does not seem to work in recent kernels or
against net-next:

  % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1
    rmgr: Cannot insert RX class rule: Operation not supported
    Cannot insert classification rule

The issue is that the existing code uses ethtool_get_flow_spec_ring_vf,
which will return a non-zero value if the ring_cookie is set to
RX_CLS_FLOW_DISC, which then causes bnxt_add_ntuple_cls_rule to return
-EOPNOTSUPP because it thinks the user is trying to set an ntuple filter
for a vf.

Fix this by first checking that the ring_cookie is not RX_CLS_FLOW_DISC.

After this patch, ntuple filters for drops can be added:

  % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1
  Added rule with ID 0

  % ethtool -n eth0
  44 RX rings available
  Total 1 rules

  Filter: 0
      Rule Type: UDP over IPv4
      Src IP addr: 1.1.1.1 mask: 0.0.0.0
      Dest IP addr: 0.0.0.0 mask: 255.255.255.255
      TOS: 0x0 mask: 0xff
      Src port: 0 mask: 0xffff
      Dest port: 0 mask: 0xffff
      Action: Drop

Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260131003042.2570434-1-joe@dama.to
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit fixes a bug where ntuple filters for packet drops (`action
-1` / `RX_CLS_FLOW_DISC`) don't work on bnxt_en network devices, despite
support being added in commit 7efd79c0e689. The user gets `-EOPNOTSUPP`
when trying to add a drop rule via ethtool. The commit message is clear,
includes a reproducer, and shows the fix working.

### Code Change Analysis

The fix is small and surgical, modifying a single file
(`bnxt_ethtool.c`) with minimal changes:

1. **The core bug**: When `ring_cookie` is set to `RX_CLS_FLOW_DISC`
   (indicating a drop action), the old code calls
   `ethtool_get_flow_spec_ring_vf(fs->ring_cookie)` which returns a non-
   zero value for `RX_CLS_FLOW_DISC`. This causes the function to
   incorrectly return `-EOPNOTSUPP`, thinking the user is trying to set
   a VF filter.

2. **The fix**: Check if `ring_cookie == RX_CLS_FLOW_DISC` first. If it
   is, skip the VF check entirely (drops don't target a VF or ring). The
   FLOW_MAC_EXT/FLOW_EXT check is also separated out for clarity.

3. **Additional cleanup**: The `ring` variable is removed;
   `ethtool_get_flow_spec_ring()` is now called inline only in the else
   branch (when it's not a drop action), which is correct since drop
   actions don't need a ring number. The `vf` variable is also removed
   since it's only used in the condition now.

### Bug Classification

This is a **real bug fix** — a feature that was intentionally added
(drop action support for ntuple filters) is broken and returns an error
to users. The `ethtool_get_flow_spec_ring_vf()` function misinterprets
`RX_CLS_FLOW_DISC` (which is `(u64)-1` / all bits set) as containing VF
information, since the VF bits are part of the upper bits of
`ring_cookie`.

### Scope and Risk Assessment

- **Lines changed**: Very small — a few lines of logic restructuring in
  one function
- **Files touched**: 1 file (`bnxt_ethtool.c`)
- **Risk**: Very low. The change only affects the ntuple filter add
  path. The logic is straightforward:
  - If `ring_cookie == RX_CLS_FLOW_DISC`, skip the VF check (correct,
    drops don't have a VF)
  - Otherwise, check for VF as before
  - The ring extraction is moved to where it's actually used (the non-
    drop path)
- **Could it break something?**: Extremely unlikely. The only behavioral
  change is that drop rules now work instead of being rejected. Non-drop
  rules follow the same logic as before.

### User Impact

- **Who is affected**: Users of Broadcom bnxt_en network adapters (very
  common in data center/enterprise environments) who want to use ethtool
  ntuple filters for packet drops
- **Severity**: Medium — the feature is completely broken, returning
  `-EOPNOTSUPP`
- **Workaround**: None apparent — the drop action simply doesn't work

### Stability Indicators

- **Reviewed-by**: Michael Chan (Broadcom maintainer for bnxt)
- **Accepted by**: Jakub Kicinski (net maintainer)
- The fix is obviously correct from reading the code

### Dependency Check

The fix is self-contained. It modifies existing code in `bnxt_ethtool.c`
that has been present since commit 7efd79c0e689 was merged. No
dependencies on other patches.

### Stable Criteria Assessment

1. **Obviously correct and tested**: Yes — reviewed by subsystem
   maintainer, clear logic
2. **Fixes a real bug**: Yes — ntuple drop filters are broken, returning
   EOPNOTSUPP
3. **Important issue**: Moderate — broken network filtering feature on a
   widely-used NIC driver
4. **Small and contained**: Yes — minimal changes to one function in one
   file
5. **No new features**: Correct — this restores functionality that was
   intended but broken
6. **Applies cleanly**: Should apply to any stable tree that has commit
   7efd79c0e689

This is a clear bug fix that restores broken functionality in a widely-
used network driver. The fix is small, obviously correct, reviewed by
the subsystem maintainer, and carries minimal risk.

**YES**

 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 068e191ede19e..c76a7623870be 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -1346,16 +1346,17 @@ static int bnxt_add_ntuple_cls_rule(struct bnxt *bp,
 	struct bnxt_l2_filter *l2_fltr;
 	struct bnxt_flow_masks *fmasks;
 	struct flow_keys *fkeys;
-	u32 idx, ring;
+	u32 idx;
 	int rc;
-	u8 vf;
 
 	if (!bp->vnic_info)
 		return -EAGAIN;
 
-	vf = ethtool_get_flow_spec_ring_vf(fs->ring_cookie);
-	ring = ethtool_get_flow_spec_ring(fs->ring_cookie);
-	if ((fs->flow_type & (FLOW_MAC_EXT | FLOW_EXT)) || vf)
+	if (fs->flow_type & (FLOW_MAC_EXT | FLOW_EXT))
+		return -EOPNOTSUPP;
+
+	if (fs->ring_cookie != RX_CLS_FLOW_DISC &&
+	    ethtool_get_flow_spec_ring_vf(fs->ring_cookie))
 		return -EOPNOTSUPP;
 
 	if (flow_type == IP_USER_FLOW) {
@@ -1481,7 +1482,7 @@ static int bnxt_add_ntuple_cls_rule(struct bnxt *bp,
 	if (fs->ring_cookie == RX_CLS_FLOW_DISC)
 		new_fltr->base.flags |= BNXT_ACT_DROP;
 	else
-		new_fltr->base.rxq = ring;
+		new_fltr->base.rxq = ethtool_get_flow_spec_ring(fs->ring_cookie);
 	__set_bit(BNXT_FLTR_VALID, &new_fltr->base.state);
 	rc = bnxt_insert_ntp_filter(bp, new_fltr, idx);
 	if (!rc) {
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match

[Sasha Levin]

From: David Woodhouse <dwmw@amazon.co.uk>

[ Upstream commit ed4d23ed469ca14d47670c0384f6ae6c4ff060a5 ]

As we finalised the spec, we spotted that vmgenid actually says that the
_HID is supposed to be hypervisor-specific. Although in the 13 years
since the original vmgenid doc was published, nobody seems to have cared
about using _HID to distinguish between implementations on different
hypervisors, and we only ever use the _CID.

For consistency, match the _CID of "VMCLOCK" too.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Babis Chalios <bchalios@amazon.es>
Tested-by: Takahiro Itazuri <itazur@amazon.com>
Link: https://patch.msgid.link/20260130173704.12575-6-itazur@amazon.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit adds a new ACPI device ID `"VMCLOCK"` to the
`vmclock_acpi_ids` match table in the `ptp_vmclock` driver. The commit
message explains that this is for consistency with the spec - the `_CID`
(Compatible ID) of "VMCLOCK" should also be matched, in addition to the
existing hypervisor-specific `_HID` "AMZNC10C".

### Code Change Analysis

The change is a single line addition:
```c
{ "VMCLOCK", 0 },
```

This adds one more ACPI device ID to the `vmclock_acpi_ids[]` table.
This is the classic "add device ID to existing driver" pattern.

### Classification

This falls squarely into the **New Device IDs** exception category.
Adding an ACPI ID to an existing driver is one of the most common and
safest types of stable backports. The driver (`ptp_vmclock`) already
exists; only a new match ID is being added so the driver can bind to
devices presenting themselves with the `VMCLOCK` compatible ID.

### Scope and Risk Assessment

- **Lines changed**: 1 line added
- **Files touched**: 1 file
- **Risk**: Extremely low - this only adds one more entry to an ACPI
  match table
- **Side effects**: None - this cannot break any existing functionality.
  It only enables the driver to match against an additional ACPI device
  identifier.

### User Impact

Without this patch, the vmclock driver will not bind to devices that
present with the `VMCLOCK` _CID instead of the `AMZNC10C` _HID. This
means virtual machines using the generic "VMCLOCK" compatible ID (as
intended by the spec) would not get vmclock functionality. This affects
users running Linux guests in hypervisor environments that use the
standard VMCLOCK ACPI identifier.

### Stability Indicators

- **Tested-by**: Takahiro Itazuri (Amazon)
- **Signed-off-by**: David Woodhouse (well-known kernel developer) and
  Jakub Kicinski (networking maintainer)
- The change is trivially correct - it's adding an entry to a static
  const table

### Dependency Check

The only dependency is that the `ptp_vmclock.c` driver must exist in the
stable tree. This driver was added relatively recently, so it may only
be present in newer stable trees. Let me check when this driver was
introduced.

Looking at the context: `ptp_vmclock.c` is a relatively new driver. If
it exists in the stable tree being targeted, this one-line device ID
addition applies trivially. If the driver doesn't exist in a particular
stable tree, the patch is simply not applicable (and not needed).

### Conclusion

This is a textbook device ID addition to an existing driver:
- One line, zero risk
- Enables hardware/virtual device support for users who need it
- Already tested
- Falls under the well-established "new device IDs" exception for stable

**YES**

 drivers/ptp/ptp_vmclock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c
index b3a83b03d9c14..cbbfc494680c7 100644
--- a/drivers/ptp/ptp_vmclock.c
+++ b/drivers/ptp/ptp_vmclock.c
@@ -591,6 +591,7 @@ static int vmclock_probe(struct platform_device *pdev)
 
 static const struct acpi_device_id vmclock_acpi_ids[] = {
 	{ "AMZNC10C", 0 },
+	{ "VMCLOCK", 0 },
 	{}
 };
 MODULE_DEVICE_TABLE(acpi, vmclock_acpi_ids);
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] ipv4: fib: Annotate access to struct fib_alias.fa_state.

[Sasha Levin]

From: Kuniyuki Iwashima <kuniyu@google.com>

[ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ]

syzbot reported that struct fib_alias.fa_state can be
modified locklessly by RCU readers. [0]

Let's use READ_ONCE()/WRITE_ONCE() properly.

[0]:
BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup

write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0:
 fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline]
 fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565
 fib_lookup include/net/ip_fib.h:390 [inline]
 ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814
 ip_route_output_key_hash net/ipv4/route.c:2705 [inline]
 __ip_route_output_key include/net/route.h:169 [inline]
 ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932
 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450
 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg net/socket.c:742 [inline]
 ____sys_sendmsg+0x53a/0x600 net/socket.c:2592
 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646
 __sys_sendmmsg+0x185/0x320 net/socket.c:2735
 __do_sys_sendmmsg net/socket.c:2762 [inline]
 __se_sys_sendmmsg net/socket.c:2759 [inline]
 __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759
 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1:
 fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline]
 fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565
 fib_lookup include/net/ip_fib.h:390 [inline]
 ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814
 ip_route_output_key_hash net/ipv4/route.c:2705 [inline]
 __ip_route_output_key include/net/route.h:169 [inline]
 ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932
 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450
 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg net/socket.c:742 [inline]
 ____sys_sendmsg+0x53a/0x600 net/socket.c:2592
 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646
 __sys_sendmmsg+0x185/0x320 net/socket.c:2735
 __do_sys_sendmmsg net/socket.c:2762 [inline]
 __se_sys_sendmmsg net/socket.c:2759 [inline]
 __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759
 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x00 -> 0x01

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260127043528.514160-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:

## Analysis of Commit: ipv4: fib: Annotate access to struct
fib_alias.fa_state

### 1. Commit Message Analysis

The commit fixes a KCSAN-detected data race in `fib_table_lookup` on
`struct fib_alias.fa_state`. The race is between concurrent RCU readers
that both read and write `fa_state` without proper annotations. The
syzbot report clearly demonstrates two tasks on different CPUs
concurrently accessing the same memory location, with one writing and
one reading.

Key indicators:
- **Reported-by: syzbot** - fuzzer-found, reproducible bug
- **KCSAN data race** - detected by kernel sanitizer
- **Reviewed-by: Simon Horman** - reviewed by a respected networking
  maintainer
- **Signed-off-by: Jakub Kicinski** - accepted by the net maintainer

### 2. Code Change Analysis

The fix is extremely surgical - it adds `READ_ONCE()`/`WRITE_ONCE()`
annotations to accesses of `fa->fa_state`:

**In `fib_lookup.h` (`fib_alias_accessed()`):**
- The read of `fa->fa_state` is changed to `READ_ONCE(fa->fa_state)`
- The write is changed to `WRITE_ONCE(fa->fa_state, fa_state |
  FA_S_ACCESSED)`
- This is the hot path - called during every FIB lookup via
  `fib_table_lookup()`

**In `fib_trie.c` (`fib_table_insert()`):**
- `state = fa->fa_state` changed to `state = READ_ONCE(fa->fa_state)`
- This reads the state of an existing alias during route replacement,
  while RCU readers may be concurrently calling `fib_alias_accessed()`

**In `fib_trie.c` (`fib_table_delete()`):**
- `fa_to_delete->fa_state & FA_S_ACCESSED` changed to
  `READ_ONCE(fa_to_delete->fa_state) & FA_S_ACCESSED`
- This reads the state during route deletion while RCU readers may be
  concurrently modifying it

### 3. Bug Mechanism

The `fib_alias_accessed()` function is called under RCU read lock by
`fib_table_lookup()`. Multiple CPUs can execute this concurrently on the
same `fib_alias`. One CPU reads `fa_state`, checks if `FA_S_ACCESSED` is
set, and if not, sets it. Another CPU does the same thing
simultaneously. Without `READ_ONCE()`/`WRITE_ONCE()`, the compiler is
free to:
- Optimize away the read (use a cached value)
- Split the write into multiple stores
- Reorder the accesses

While the practical consequence here is relatively benign (the worst
case is a redundant cache flush or a missed `FA_S_ACCESSED` marking),
the data race is undefined behavior per the C standard and KCSAN
correctly flags it. These annotations are the standard Linux kernel
pattern for fixing such races.

### 4. Scope and Risk Assessment

- **Lines changed:** ~6 lines of actual code change across 2 files
- **Files touched:** 2 (both in the same subsystem: IPv4 FIB)
- **Risk:** Extremely low - `READ_ONCE()`/`WRITE_ONCE()` are transparent
  compiler barriers that don't change the logic
- **Subsystem:** Core IPv4 routing (FIB lookup) - very widely used
- **Could break something:** No. These annotations only prevent compiler
  optimizations that would be incorrect for concurrent access

### 5. User Impact

- **Who is affected:** Every system doing IPv4 routing (essentially all
  Linux systems)
- **Severity:** The data race itself is in a very hot path. While the
  practical consequence is low (it's a "set once" flag), undefined
  behavior in the kernel is always worth fixing
- **KCSAN noise:** Without this fix, KCSAN-enabled kernels will keep
  reporting this race, which affects kernel testing and development

### 6. Stable Kernel Criteria

- **Obviously correct:** Yes - textbook `READ_ONCE()`/`WRITE_ONCE()`
  annotation
- **Fixes a real bug:** Yes - KCSAN-detected data race, undefined
  behavior
- **Small and contained:** Yes - 6 lines across 2 files in one subsystem
- **No new features:** Correct - pure annotation fix
- **Tested:** Reviewed by Simon Horman, merged by Jakub Kicinski

### 7. Dependencies

No dependencies on other commits. `READ_ONCE()`/`WRITE_ONCE()` have been
available in the kernel for many years. The `fib_alias_accessed()`
function and `fa_state` field exist in all stable trees.

### Conclusion

This is a small, surgical fix for a KCSAN-detected data race in core
IPv4 FIB lookup code. It uses the standard `READ_ONCE()`/`WRITE_ONCE()`
pattern, has essentially zero risk of regression, and fixes undefined
behavior in one of the most heavily used kernel paths. It was reported
by syzbot, reviewed by a networking maintainer, and merged by the net
maintainer.

**YES**

 net/ipv4/fib_lookup.h | 6 ++++--
 net/ipv4/fib_trie.c   | 4 ++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
index f9b9e26c32c19..0b72796dd1ad3 100644
--- a/net/ipv4/fib_lookup.h
+++ b/net/ipv4/fib_lookup.h
@@ -28,8 +28,10 @@ struct fib_alias {
 /* Don't write on fa_state unless needed, to keep it shared on all cpus */
 static inline void fib_alias_accessed(struct fib_alias *fa)
 {
-	if (!(fa->fa_state & FA_S_ACCESSED))
-		fa->fa_state |= FA_S_ACCESSED;
+	u8 fa_state = READ_ONCE(fa->fa_state);
+
+	if (!(fa_state & FA_S_ACCESSED))
+		WRITE_ONCE(fa->fa_state, fa_state | FA_S_ACCESSED);
 }
 
 /* Exported by fib_semantics.c */
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 7e2c17fec3fc4..1308213791f19 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1280,7 +1280,7 @@ int fib_table_insert(struct net *net, struct fib_table *tb,
 			new_fa->fa_dscp = fa->fa_dscp;
 			new_fa->fa_info = fi;
 			new_fa->fa_type = cfg->fc_type;
-			state = fa->fa_state;
+			state = READ_ONCE(fa->fa_state);
 			new_fa->fa_state = state & ~FA_S_ACCESSED;
 			new_fa->fa_slen = fa->fa_slen;
 			new_fa->tb_id = tb->tb_id;
@@ -1745,7 +1745,7 @@ int fib_table_delete(struct net *net, struct fib_table *tb,
 
 	fib_remove_alias(t, tp, l, fa_to_delete);
 
-	if (fa_to_delete->fa_state & FA_S_ACCESSED)
+	if (READ_ONCE(fa_to_delete->fa_state) & FA_S_ACCESSED)
 		rt_cache_flush(cfg->fc_nlinfo.nl_net);
 
 	fib_release_info(fa_to_delete->fa_info);
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] net: sfp: add quirk for Lantech 8330-265D

[Sasha Levin]

From: Marek Behún <kabel@kernel.org>

[ Upstream commit 86a8e8e0ddbc3d14c799536eb888180b84d002f3 ]

Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports
2500MBd instead of 3125MBd.

Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal
inverted RX_LOS. We therefore need to ignore RX_LOS on these modules.

Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://patch.msgid.link/20260128170044.15576-1-kabel@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 SFP Quirk Addition for Lantech 8330-265D

### Commit Message Analysis

The commit adds a hardware quirk for the Lantech 8330-265D SFP module.
It addresses two specific hardware issues:

1. **Incorrect speed reporting**: The module reports 2500MBd instead of
   the correct 3125MBd in its EEPROM, preventing it from being
   recognized as a 2500base-X capable module.
2. **Inverted RX_LOS signal**: Some units of this module report inverted
   Loss-of-Signal, while the EEPROM claims normal LOS behavior. Since
   the behavior is inconsistent across units, the fix ignores LOS
   entirely.

The commit explicitly references similarity to an existing quirk
(Lantech 8330-262D-E), establishing a pattern.

### Code Change Analysis

The change is minimal and contained:
- **2 lines added**: A new `SFP_QUIRK()` entry for "Lantech" /
  "8330-265D" with `sfp_quirk_2500basex` and `sfp_fixup_ignore_los`
- **Comment updated**: The existing comment for the 8330-262D-E is
  expanded to cover the 8330-265D as well, and explains the LOS issue
- **No new functions or infrastructure**: Uses existing quirk macros
  (`SFP_QUIRK`) and existing fixup functions (`sfp_quirk_2500basex`,
  `sfp_fixup_ignore_los`)

### Classification: Hardware Quirk

This falls squarely into the **SFP/Network Quirks** exception category
explicitly mentioned in the stable backport guidelines. SFP quirks for
optical modules with broken behavior are specifically called out as
appropriate for stable trees.

### Risk Assessment

- **Risk: Extremely Low** — The quirk only triggers for modules with
  vendor string "Lantech" and product string "8330-265D". It cannot
  affect any other hardware.
- **Scope: Minimal** — Two lines of data-driven code in an existing
  quirk table. No logic changes.
- **Dependencies: None** — The `SFP_QUIRK` macro, `sfp_quirk_2500basex`,
  and `sfp_fixup_ignore_los` all already exist in the codebase. This
  commit is fully self-contained.

### User Impact

Without this quirk:
- The Lantech 8330-265D SFP module **cannot operate at 2500base-X**
  because the kernel misinterprets its EEPROM data
- Some units exhibit **random link drops or failure to establish link**
  due to inverted RX_LOS being treated as actual signal loss

These are real, user-impacting hardware issues that make the SFP module
non-functional or unreliable.

### Stability Indicators

- Author is **Marek Behún**, the SFP subsystem maintainer — he deeply
  understands this code
- Reviewed and merged by **Jakub Kicinski**, the networking subsystem
  maintainer
- Follows an established pattern (identical approach to existing
  8330-262D-E quirk)
- The fixup functions used (`sfp_quirk_2500basex`,
  `sfp_fixup_ignore_los`) are well-tested and used by other quirk
  entries

### Conclusion

This is a textbook example of a hardware quirk that belongs in stable
trees. It's a tiny, self-contained, zero-risk addition to an existing
quirk table that makes specific hardware work correctly. It uses only
pre-existing infrastructure, was authored and reviewed by the relevant
maintainers, and fixes real hardware issues (incorrect speed negotiation
and unreliable link due to inverted LOS).

**YES**

 drivers/net/phy/sfp.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 3e023723887c4..43aefdd8b70f7 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -532,9 +532,13 @@ static const struct sfp_quirk sfp_quirks[] = {
 	SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex,
 		  sfp_fixup_ignore_tx_fault),
 
-	// Lantech 8330-262D-E can operate at 2500base-X, but incorrectly report
-	// 2500MBd NRZ in their EEPROM
+	// Lantech 8330-262D-E and 8330-265D can operate at 2500base-X, but
+	// incorrectly report 2500MBd NRZ in their EEPROM.
+	// Some 8330-265D modules have inverted LOS, while all of them report
+	// normal LOS in EEPROM. Therefore we need to ignore LOS entirely.
 	SFP_QUIRK_S("Lantech", "8330-262D-E", sfp_quirk_2500basex),
+	SFP_QUIRK("Lantech", "8330-265D", sfp_quirk_2500basex,
+		  sfp_fixup_ignore_los),
 
 	SFP_QUIRK_S("UBNT", "UF-INSTANT", sfp_quirk_ubnt_uf_instant),
 
-- 
2.51.0