From: Joshua Watt jpewhacker@gmail.com
[ Upstream commit 9bb3baa9d1604cd20f49ae7dac9306b4037a0e7a ]
Since the last renewal time was initialized to 0 and jiffies start counting at -5 minutes, any clients connected in the first 5 minutes after a reboot would have their renewal timer set to a very long interval. If the connection was idle, this would result in the client state timing out on the server and the next call to the server would return NFS4ERR_BADSESSION.
Fix this by initializing the last renewal time to the current jiffies instead of 0.
Signed-off-by: Joshua Watt jpewhacker@gmail.com Signed-off-by: Anna Schumaker anna.schumaker@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my comprehensive analysis using semantic code analysis tools and repository examination, here is my assessment:
## **ANSWER: YES**
This commit should **DEFINITELY** be backported to stable kernel trees.
---
## **DETAILED ANALYSIS**
### **1. Semantic Code Analysis Performed**
I used the following tools to analyze this commit:
- **mcp__semcode__find_function**: Located `nfs4_alloc_client` function definition and structure - **mcp__semcode__find_type**: Examined the `nfs_client` struct to understand the `cl_last_renewal` field - **mcp__semcode__find_callers**: Found that `nfs4_schedule_state_renewal` is called by 5 functions - **mcp__semcode__grep_functions**: Identified all 5 functions that use `cl_last_renewal` field - **Git analysis**: Traced the field's history back to 2006 (kernel v2.6.19)
### **2. Code Changes Analysis**
The fix is a **single line addition** in `fs/nfs/nfs4client.c:224`: ```c clp->cl_last_renewal = jiffies; ```
This initialization occurs in `nfs4_alloc_client()`, which is called indirectly through the function pointer `.alloc_client` in the `nfs_subversion` operations structure (found at `fs/nfs/nfs4proc.c:11032`).
### **3. Bug Impact Assessment**
**How cl_last_renewal is Used:**
The field is critical in `nfs4_schedule_state_renewal()` (fs/nfs/nfs4renewd.c:119-120): ```c timeout = (2 * clp->cl_lease_time) / 3 + (long)clp->cl_last_renewal - (long)jiffies; ```
**The Bug:** - `jiffies` starts at `INITIAL_JIFFIES` (approximately -300*HZ, or -5 minutes) - `cl_last_renewal` was initialized to 0 (implicit, never explicitly set) - During the first 5 minutes after boot: `timeout = (2*lease_time)/3 + 0 - (-300*HZ)` - This **adds an extra 5 minutes** to the renewal timeout
**User Impact:** - Affects **all NFSv4 clients** created in the first 5 minutes after system boot - If the connection is idle during this period, the client state **times out on the server** - Next NFS operation returns **NFS4ERR_BADSESSION** - Users experience connection failures requiring session re- establishment
### **4. Scope and Risk Analysis**
**Scope:** - **Extremely contained**: One line, one function, one subsystem - **No dependencies**: Doesn't rely on any new kernel features - **No API changes**: Internal field initialization only - **Pattern-consistent**: `nfs4_init_ds_session` (fs/nfs/nfs4session.c:643) already uses the same initialization pattern
**Risk:** - **Minimal regression risk**: Just initializing a timestamp field correctly - **Well-tested pattern**: Same initialization exists elsewhere in the codebase
### **5. Historical Context**
- **Bug age**: Present since **2006** (kernel v2.6.19-rc1, commit 24c8dbbb5f777) - **Affects**: Nearly **20 years** of kernel releases - **Precedent**: Similar NFSv4 renewal bugs have been backported (e.g., commit 2c9d556d14bc8 from 2014 addressing another state renewal regression) - **Missing tags**: No "Fixes:" or "Cc: stable@vger.kernel.org" tags suggest the maintainer may not have considered stable backporting
### **6. Stable Tree Compliance**
✅ **Bug fix** (not a new feature) ✅ **Important** (causes user-facing failures) ✅ **Small and contained** (one line) ✅ **No architectural changes** ✅ **Low regression risk** ✅ **Widely used subsystem** (NFSv4 is critical in enterprise environments) ✅ **Long-standing bug** (affects many LTS kernels)
---
## **CONCLUSION**
This is a **textbook example** of a commit that should be backported: - Fixes a real, user-facing bug (NFS4ERR_BADSESSION errors) - Extremely simple one-line fix with no dependencies - Affects a critical subsystem (NFSv4 client) - Bug has existed for ~20 years, affecting many stable releases - Minimal risk of regression - Follows established initialization patterns in the codebase
The lack of explicit stable tags appears to be an oversight rather than an intentional decision to exclude it from stable trees.
fs/nfs/nfs4client.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c index 6fddf43d729c8..5998d6bd8a4f4 100644 --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -222,6 +222,7 @@ struct nfs_client *nfs4_alloc_client(const struct nfs_client_initdata *cl_init) clp->cl_state = 1 << NFS4CLNT_LEASE_EXPIRED; clp->cl_mvops = nfs_v4_minor_ops[cl_init->minorversion]; clp->cl_mig_gen = 1; + clp->cl_last_renewal = jiffies; #if IS_ENABLED(CONFIG_NFS_V4_1) init_waitqueue_head(&clp->cl_lock_waitq); #endif