From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Yang Li <yang.li85200@gmail.com>, Guo Ren <guoren@kernel.org>,
Sasha Levin <sashal@kernel.org>,
viro@zeniv.linux.org.uk, linux-csky@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-5.15] csky: fix csky_cmpxchg_fixup not working
Date: Fri, 12 Dec 2025 01:12:13 -0500 [thread overview]
Message-ID: <20251212061223.305139-3-sashal@kernel.org> (raw)
In-Reply-To: <20251212061223.305139-1-sashal@kernel.org>
From: Yang Li <yang.li85200@gmail.com>
[ Upstream commit 809ef03d6d21d5fea016bbf6babeec462e37e68c ]
In the csky_cmpxchg_fixup function, it is incorrect to use the global
variable csky_cmpxchg_stw to determine the address where the exception
occurred.The global variable csky_cmpxchg_stw stores the opcode at the
time of the exception, while &csky_cmpxchg_stw shows the address where
the exception occurred.
Signed-off-by: Yang Li <yang.li85200@gmail.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of csky: fix csky_cmpxchg_fixup not working
### 1. COMMIT MESSAGE ANALYSIS
**Subject**: "csky: fix csky_cmpxchg_fixup not working" - clearly
indicates a bug fix
**Key issue explained**: The commit message describes a fundamental
semantic error - the code was using the **value** of `csky_cmpxchg_stw`
(which contains an opcode) when it should have been using the
**address** of `csky_cmpxchg_stw` (where the instruction is located).
**Missing tags**: No "Cc: stable@vger.kernel.org" or "Fixes:" tag, but
this doesn't preclude backporting if the fix is clearly warranted.
### 2. CODE CHANGE ANALYSIS
The change is extremely surgical - only 2 lines modified:
```c
- if (instruction_pointer(regs) == csky_cmpxchg_stw)
- instruction_pointer_set(regs, csky_cmpxchg_ldw);
+ if (instruction_pointer(regs) == (unsigned
long)&csky_cmpxchg_stw)
+ instruction_pointer_set(regs, (unsigned
long)&csky_cmpxchg_ldw);
```
**Technical explanation**:
- `csky_cmpxchg_ldw` and `csky_cmpxchg_stw` are external symbols
declared as `extern unsigned long` - they represent labels/addresses
in the cmpxchg assembly implementation
- The **value** stored at these symbols is the opcode of the instruction
- The **address** (`&csky_cmpxchg_stw`) is where the instruction resides
in memory
- The code compares against `instruction_pointer(regs)` which is an
address, so it must compare against an address, not an opcode value
**Root cause**: Simple semantic error - using value instead of address
**Why the bug is severe**: This function handles TLB modification faults
during compare-and-exchange operations. When such a fault occurs at the
store instruction, the handler should redirect execution back to the
load instruction to retry the operation. With the bug, the comparison
`instruction_pointer(regs) == csky_cmpxchg_stw` would almost never match
(comparing an address to an opcode), so the fixup **never worked**.
### 3. CLASSIFICATION
- **Bug fix**: Yes, clearly fixing broken functionality
- **Security impact**: Potentially - broken cmpxchg can lead to race
conditions
- **Data corruption risk**: Yes - atomic operations that don't work
correctly can cause data races
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed**: 2 lines
- **Files touched**: 1 file (arch/csky/mm/fault.c)
- **Subsystem**: CSKY architecture-specific code
- **Complexity**: Minimal - straightforward address-of fix
- **Risk**: Very low - the fix is obviously correct and architecture-
specific
### 5. USER IMPACT
- **Affected users**: CSKY systems without LDSTEX instructions (when
`CONFIG_CPU_HAS_LDSTEX` is not defined)
- **Severity**: High - broken compare-and-exchange atomic operations can
cause:
- Race conditions in concurrent code
- Data corruption
- Deadlocks
- Unpredictable behavior in any code using cmpxchg
### 6. STABILITY INDICATORS
- Signed-off by maintainer Guo Ren (CSKY maintainer)
- The fix is logically obvious once understood
### 7. DEPENDENCY CHECK
- No dependencies on other commits
- The affected code has existed since CSKY was added to the kernel
- Should apply cleanly to stable trees that have CSKY support
### CONCLUSION
This commit clearly meets all stable kernel criteria:
1. **Obviously correct**: The fix is a textbook case of using
`&variable` (address) instead of `variable` (value) when comparing
against an instruction pointer
2. **Fixes a real bug**: The cmpxchg fixup mechanism was completely non-
functional
3. **Important issue**: Broken atomic operations can cause data
corruption, race conditions, and system instability
4. **Small and contained**: Only 2 lines changed in one file,
architecture-specific
5. **No new features**: Just fixing existing functionality to actually
work
The absence of stable tags appears to be an oversight. This is a
critical fix for CSKY platforms - without it, the entire cmpxchg fixup
path is dead code that never triggers when it should.
**YES**
arch/csky/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/csky/mm/fault.c b/arch/csky/mm/fault.c
index a6ca7dff42153..7ff4011089850 100644
--- a/arch/csky/mm/fault.c
+++ b/arch/csky/mm/fault.c
@@ -45,8 +45,8 @@ static inline void csky_cmpxchg_fixup(struct pt_regs *regs)
if (trap_no(regs) != VEC_TLBMODIFIED)
return;
- if (instruction_pointer(regs) == csky_cmpxchg_stw)
- instruction_pointer_set(regs, csky_cmpxchg_ldw);
+ if (instruction_pointer(regs) == (unsigned long)&csky_cmpxchg_stw)
+ instruction_pointer_set(regs, (unsigned long)&csky_cmpxchg_ldw);
return;
}
#endif
--
2.51.0
next prev parent reply other threads:[~2025-12-12 6:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 6:12 [PATCH AUTOSEL 6.18-5.10] alpha: don't reference obsolete termio struct for TC* constants Sasha Levin
2025-12-12 6:12 ` [PATCH AUTOSEL 6.18-5.10] ARM: 9461/1: Disable HIGHPTE on PREEMPT_RT kernels Sasha Levin
2025-12-12 6:12 ` Sasha Levin [this message]
2025-12-12 6:12 ` [PATCH AUTOSEL 6.18-6.6] dm-snapshot: fix 'scheduling while atomic' on real-time kernels Sasha Levin
2025-12-12 6:12 ` [PATCH AUTOSEL 6.18-6.17] dm-verity: disable recursive forward error correction Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251212061223.305139-3-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=guoren@kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yang.li85200@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox