From: Samuel Holland samuel.holland@sifive.com
[ Upstream commit 5898fc01ff344075e4332aa9abeb0841c85e7e51 ]
This definition is used by zsmalloc to optimize memory allocation. On riscv64, it is the same as MAX_PHYSMEM_BITS from asm/sparsemem.h, but that definition depends on CONFIG_SPARSEMEM. The correct definition is already provided for riscv32.
Signed-off-by: Samuel Holland samuel.holland@sifive.com Link: https://lore.kernel.org/r/20251015233327.3885003-1-samuel.holland@sifive.com Signed-off-by: Paul Walmsley pjw@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my comprehensive analysis of this commit using repository examination and code analysis, here is my assessment:
## **Backport Status: YES**
## Detailed Analysis
### 1. Code Change Analysis
The commit adds a single line to `arch/riscv/include/asm/pgtable-64.h`: ```c #define MAX_POSSIBLE_PHYSMEM_BITS 56 ```
This definition is required by zsmalloc (used by ZRAM/ZSWAP) for correct memory allocation calculations.
### 2. Tools Used and Findings
**Repository Investigation:** - **Grep searches** revealed that MAX_POSSIBLE_PHYSMEM_BITS is: - Already defined for riscv32 (34 bits) - Defined for all other major architectures (x86, arm64, powerpc, mips, arc, arm) - Missing for riscv64 (this is the bug being fixed)
- **Code analysis of mm/zsmalloc.c** (lines 65-77, 91-92) shows: - zsmalloc uses `_PFN_BITS = (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)` - OBJ_INDEX_BITS = (BITS_PER_LONG - _PFN_BITS) - Without MAX_POSSIBLE_PHYSMEM_BITS, it falls back to MAX_PHYSMEM_BITS or BITS_PER_LONG
- **Examined arch/riscv/include/asm/sparsemem.h** which defines MAX_PHYSMEM_BITS as 56, but only when `CONFIG_SPARSEMEM` is enabled
**Impact Analysis:** Without this fix on riscv64 systems where CONFIG_SPARSEMEM is disabled: - Incorrect: _PFN_BITS = 64 - 12 = **52 bits** (using BITS_PER_LONG fallback) - Correct: _PFN_BITS = 56 - 12 = **44 bits** - This causes OBJ_INDEX_BITS to be 12 bits instead of 20 bits - Affects ZS_MIN_ALLOC_SIZE calculations and entire zsmalloc size class system
### 3. Historical Context Investigation
**Git history analysis** revealed critical information: - Commit **f0bbc41760557** (2021) fixed this exact issue for ARM, MIPS, PowerPC, and other architectures - That 2021 commit: - Was triggered by actual kernel crashes (NULL pointer dereference in zs_map_object) - Had "Fixes:" tags pointing to zsmalloc - Was backported to stable kernels (signed-off by Sasha Levin) - Documented real-world bug report: "Unable to handle kernel NULL pointer dereference" - riscv was NOT included in that 2021 fix (likely because riscv64 support was incomplete then) - The current commit (5898fc01ff344) completes that 2021 work for riscv64
### 4. Configuration Analysis
**Examined arch/riscv/Kconfig**: - ARCH_SPARSEMEM_ENABLE is optional (`def_bool y` depends on MMU) - Users CAN choose FLATMEM instead of SPARSEMEM - Default config has `CONFIG_SPARSEMEM_MANUAL=y`, but this is not mandatory - Without CONFIG_SPARSEMEM, MAX_PHYSMEM_BITS is undefined, triggering the bug
### 5. Subsystem Criticality
**Memory Management Impact:** - zsmalloc is used by ZRAM (compressed RAM) and ZSWAP (compressed swap) - These are important for memory-constrained systems - Incorrect calculations could lead to: - Memory corruption - Kernel crashes - Data loss
### 6. Backport Indicators
**Against backporting:** - No "Cc: stable@vger.kernel.org" tag - No "Fixes:" tag - Limited scope (only affects specific config combinations)
**For backporting:** - **Critical**: Identical bug was backported for other architectures in 2021 - **Precedent**: This is completing a known stable-backport pattern - **Safety**: Minimal change (single line), no side effects - **Correctness**: Fixes mathematically incorrect value that can cause crashes - **Stable Rules Compliance**: Pure bug fix, no new features, no architectural changes
### 7. Risk Assessment
**Regression Risk: VERY LOW** - Single constant definition - No behavioral changes - Only affects riscv64 - Mirrors existing definitions for other architectures - Value (56) matches the PFN_MASK in the same file (GENMASK(53, 10))
**Impact if NOT backported:** - Users building riscv64 kernels without CONFIG_SPARSEMEM will have broken zsmalloc - Potential for kernel crashes similar to the 2021 ARM bug report - Data corruption in ZRAM/ZSWAP scenarios
## Conclusion
This commit SHOULD be backported because:
1. **It fixes the same bug that was considered serious enough to backport for other architectures in 2021** 2. **The 2021 fix caused real kernel crashes that were documented** 3. **It's a minimal, safe change with no regression risk** 4. **It follows stable kernel rules: fixes bug, no new features, no architectural changes** 5. **riscv64 was simply missed in the 2021 fix, and this commit completes that work**
The lack of explicit stable tags is likely an oversight, as this is clearly a bug fix following the pattern of previous stable-backported commits for the same issue on other architectures.
arch/riscv/include/asm/pgtable-64.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h index 1018d22169013..6e789fa58514c 100644 --- a/arch/riscv/include/asm/pgtable-64.h +++ b/arch/riscv/include/asm/pgtable-64.h @@ -69,6 +69,8 @@ typedef struct {
#define PTRS_PER_PMD (PAGE_SIZE / sizeof(pmd_t))
+#define MAX_POSSIBLE_PHYSMEM_BITS 56 + /* * rv64 PTE format: * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0