[PATCH AUTOSEL 7.0-5.10] FDDI: defxx: Rate-limit memory allocation errors

[Sasha Levin <sashal@kernel.org>]

From: "Maciej W. Rozycki" <macro@orcam.me.uk>

[ Upstream commit 7fae6616704a17c64438ad4b73a6effa6c03ffda ]

Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure, e.g.:

[...]
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 	0-...!: (332 ticks this GP) idle=255c/1/0x40000000 softirq=16420123/16420123 fqs=0
rcu: 	(t=2103 jiffies g=35680089 q=4 ncpus=1)
rcu: rcu_sched kthread timer wakeup didn't happen for 2102 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: 	Possible timer handling issue on cpu=0 timer-softirq=12779658
rcu: rcu_sched kthread starved for 2103 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: 	Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_sched       state:I stack:0     pid:14    tgid:14    ppid:2      flags:0x00004000
Call Trace:
 __schedule+0x258/0x580
 schedule+0x19/0xa0
 schedule_timeout+0x4a/0xb0
 ? hrtimers_cpu_dying+0x1b0/0x1b0
 rcu_gp_fqs_loop+0xb1/0x450
 rcu_gp_kthread+0x9d/0x130
 kthread+0xb2/0xe0
 ? rcu_gp_init+0x4a0/0x4a0
 ? kthread_park+0x90/0x90
 ret_from_fork+0x2d/0x50
 ? kthread_park+0x90/0x90
 ret_from_fork_asm+0x12/0x20
 entry_INT80_32+0x10d/0x10d
CPU: 0 UID: 500 PID: 21895 Comm: 31370.exe Not tainted 6.13.0-dirty #2

(here running the libstdc++-v3 testsuite).

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/alpine.DEB.2.21.2603291236590.60268@angie.orcam.me.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** `FDDI: defxx:` (FDDI network driver, DEC FDDI
  controllers)
- **Action verb:** "Rate-limit" — this implies controlling the frequency
  of something
- **Summary:** Rate-limit memory allocation error messages to prevent
  system instability

### Step 1.2: Tags
- **Signed-off-by:** Maciej W. Rozycki `<macro@orcam.me.uk>` — **the
  driver maintainer** (verified from line 24 of defxx.c)
- **Reviewed-by:** Andrew Lunn `<andrew@lunn.ch>` — well-known
  networking reviewer
- **Link:** patch.msgid.link URL (lore.kernel.org was blocked by Anubis)
- **Signed-off-by:** Jakub Kicinski `<kuba@kernel.org>` — **the net
  subsystem maintainer** (applied by him)
- No Fixes: tag, no Cc: stable, no Reported-by — expected for manual
  review candidates

### Step 1.3: Commit Body
The commit describes a **real observed problem**: under memory pressure,
the unlimited `printk()` in the receive path floods the console so badly
that it causes:
- RCU stall (`rcu_sched self-detected stall on CPU`)
- RCU kthread starvation (`rcu_sched kthread starved for 2103 jiffies!`)
- System becoming "unstable or unusable"
- The message "Unless rcu_sched kthread gets sufficient CPU time, OOM is
  now expected behavior"

A full stack trace is provided showing the real crash scenario. The
trigger was running the libstdc++-v3 testsuite, causing memory pressure
leading to allocation failures in the receive path.

### Step 1.4: Hidden Bug Fix Detection
This IS a bug fix, not a cosmetic change. The unlimited printk in a hot
interrupt-driven receive path causes:
1. Console flooding → CPU time consumed by printk
2. RCU stalls → system instability
3. Potential OOM due to RCU kthread starvation

The fix prevents a **soft lockup/RCU stall** which is a serious system
stability issue.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed:** 1 (`drivers/net/fddi/defxx.c`)
- **Lines changed:** 1 line modified (`printk` → `printk_ratelimited`)
- **Function modified:** `dfx_rcv_queue_process()`
- **Scope:** Single-file, single-line, surgical fix

### Step 2.2: Code Flow Change
- **Before:** Every failed `netdev_alloc_skb()` in the receive path
  prints an unrestricted message via `printk()`
- **After:** The same message is printed via `printk_ratelimited()`,
  which limits output to
  DEFAULT_RATELIMIT_INTERVAL/DEFAULT_RATELIMIT_BURST (typically 5
  seconds/10 messages)
- **Execution path affected:** The error/failure path within the
  interrupt-driven packet receive handler

### Step 2.3: Bug Mechanism
This is a **system stability fix** — the unlimited printk in a hot path
(interrupt handler → receive queue processing) causes:
- Console output flooding
- CPU starvation for other kernel threads (RCU)
- RCU stalls leading to system hang

Category: **Performance/stability fix that prevents soft lockups and RCU
stalls** — this is a CRITICAL stability issue, not a mere optimization.

### Step 2.4: Fix Quality
- **Obviously correct:** Yes. `printk_ratelimited()` is a drop-in
  replacement for `printk()` with rate limiting. It's a well-established
  kernel API.
- **Minimal/surgical:** Yes — exactly 1 line changed, same format
  string, same arguments.
- **Regression risk:** Virtually none. The only behavioral difference is
  fewer log messages under sustained failure, which is the desired
  behavior.
- **Red flags:** None.

---

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
The buggy `printk` line dates back to commit `1da177e4c3f41` — the
**initial Linux git import** (April 2005, Linux 2.6.12-rc2). This code
has been present in every kernel version since the beginning of git
history, meaning **all active stable trees** contain this bug.

### Step 3.2: Fixes Tag
No Fixes: tag present (expected for manual review candidates).

### Step 3.3: File History
The file has had very few changes in recent history (only 1 change since
v6.1 — `HAS_IOPORT` dependencies). This means the fix will apply cleanly
to all stable trees.

### Step 3.4: Author
Maciej W. Rozycki is the **listed maintainer** of the defxx driver (line
24: "Maintainers: macro Maciej W. Rozycki <macro@orcam.me.uk>"). This is
a fix from the subsystem maintainer who encountered the issue firsthand.

### Step 3.5: Dependencies
None. `printk_ratelimited` has been available in the kernel since ~2010.
No prerequisites needed.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.5
The lore.kernel.org and patch.msgid.link URLs were blocked by Anubis
anti-bot protection. However:
- The patch was **reviewed by Andrew Lunn** (well-known net reviewer)
- The patch was **applied by Jakub Kicinski** (net subsystem maintainer)
- The commit message includes a detailed real-world reproduction
  scenario

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
- `dfx_rcv_queue_process()` — the function where the change is made

### Step 5.2: Callers
- Called from `dfx_int_common()` (line 1889), which is the interrupt
  service routine
- `dfx_int_common()` is called from `dfx_interrupt()` (lines 1972, 1998,
  2023) — the hardware IRQ handler
- This is called on **every received packet interrupt**, making it a hot
  path

### Step 5.3-5.4: Call Chain
The call chain is: `Hardware IRQ → dfx_interrupt() → dfx_int_common() →
dfx_rcv_queue_process() → [allocation failure] → printk()`

Under memory pressure, every incoming packet that fails allocation
triggers the printk. On an active FDDI network (100 Mbit/s), this could
be thousands of packets per second, each generating a printk call —
overwhelming the system.

### Step 5.5: Similar Patterns
There are many other `printk("Could not...")` calls in the driver (11
total), but only this one is in a hot interrupt-driven path where rapid
repetition is possible.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
The buggy code has been present since the initial git import (2005). It
exists in **all stable trees** (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y,
6.12.y, etc.).

### Step 6.2: Backport Complications
The file has had minimal changes. The printk line is unchanged since
2005. The patch will apply **cleanly** to all active stable trees.

### Step 6.3: Related Fixes
No related fixes for this specific issue found in stable.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Path:** `drivers/net/fddi/` — FDDI networking driver
- **Criticality:** PERIPHERAL — FDDI is a legacy technology, but there
  are real users (the maintainer himself encountered this bug while
  testing)

### Step 7.2: Activity
Very low activity — the file has had only a handful of changes in recent
years. This is mature, stable code.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Population
Users of DEC FDDI controllers (DEFTA/DEFEA/DEFPA) under memory pressure.
While this is a niche user base, the fix is risk-free for everyone.

### Step 8.2: Trigger Conditions
- System must be under memory pressure (allocation failures)
- FDDI interface must be receiving packets
- The combination causes printk flooding → RCU stalls → system hang
- Triggered in real life (libstdc++ testsuite causing memory pressure)

### Step 8.3: Failure Mode Severity
- **RCU stall / soft lockup → CRITICAL** (system becomes
  unusable/unstable)
- Can lead to OOM as stated in the RCU warning
- Data loss risk from system hang

### Step 8.4: Risk-Benefit Ratio
- **Benefit:** Prevents system hang/RCU stall under memory pressure —
  HIGH
- **Risk:** 1 line change, `printk` → `printk_ratelimited`, well-
  established API — VERY LOW
- **Ratio:** Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes a real RCU stall / system instability issue with concrete
  reproduction
- Single-line, obviously correct change (`printk` →
  `printk_ratelimited`)
- Fix is from the driver maintainer who observed the bug firsthand
- Reviewed by Andrew Lunn, applied by Jakub Kicinski (net maintainer)
- Buggy code exists in all stable trees since 2005
- Patch applies cleanly — no dependencies, no conflicts expected
- Zero regression risk

**AGAINST backporting:**
- FDDI is a legacy/niche technology with a small user base
- The trigger requires specific conditions (memory pressure + active
  FDDI traffic)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — author encountered and
   reproduced it; 1-line drop-in replacement
2. **Fixes a real bug?** YES — RCU stall / system hang under memory
   pressure
3. **Important issue?** YES — system instability, RCU stalls, potential
   OOM
4. **Small and contained?** YES — single line change in a single file
5. **No new features or APIs?** YES — no new features
6. **Can apply to stable trees?** YES — code unchanged since 2005, clean
   apply expected

### Step 9.3: Exception Categories
Not an exception category — this is a straightforward bug fix.

### Step 9.4: Decision
This is a minimal, zero-risk fix for a real system stability issue (RCU
stalls). It meets all stable kernel criteria.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Andrew Lunn, applied by Jakub
  Kicinski (net maintainer SOB)
- [Phase 1] Commit body includes full RCU stall stack trace
  demonstrating the real-world bug
- [Phase 2] Diff: exactly 1 line changed in `dfx_rcv_queue_process()`,
  `printk` → `printk_ratelimited`
- [Phase 3] git blame: buggy printk line from `1da177e4c3f41` (initial
  git import, 2005), present in all stable trees
- [Phase 3] git log --author: Maciej W. Rozycki is the driver maintainer
  (confirmed from file header line 24)
- [Phase 3] git log v6.6../v6.1../v5.15.. -- defxx.c: minimal changes,
  patch will apply cleanly
- [Phase 4] b4 dig and WebFetch: lore blocked by Anubis; could not
  verify mailing list discussion directly
- [Phase 5] Callers traced: `dfx_interrupt()` → `dfx_int_common()` →
  `dfx_rcv_queue_process()` — this is a hardware IRQ path, hot path for
  every received packet
- [Phase 5] Grep confirmed: `printk_ratelimited` is a well-established
  macro in `include/linux/printk.h`
- [Phase 6] Code present in all stable trees (unchanged since 2005)
- [Phase 8] Failure mode: RCU stall → system hang, severity CRITICAL
- UNVERIFIED: Could not access lore.kernel.org discussion due to Anubis
  protection; however, the commit message and review tags provide
  sufficient evidence

**YES**

 drivers/net/fddi/defxx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
index 0fbbb7286008d..6b8cfbee3b9d6 100644
--- a/drivers/net/fddi/defxx.c
+++ b/drivers/net/fddi/defxx.c
@@ -3182,7 +3182,7 @@ static void dfx_rcv_queue_process(
 							       pkt_len + 3);
 				if (skb == NULL)
 					{
-					printk("%s: Could not allocate receive buffer.  Dropping packet.\n", bp->dev->name);
+					printk_ratelimited("%s: Could not allocate receive buffer.  Dropping packet.\n", bp->dev->name);
 					bp->rcv_discards++;
 					break;
 					}
-- 
2.53.0