[PATCH AUTOSEL 6.17-6.1] riscv: mm: Define MAX_POSSIBLE_PHYSMEM_BITS for zsmalloc

[Sasha Levin]

From: Samuel Holland <samuel.holland at 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 at sifive.com>
Link: https://lore.kernel.org/r/20251015233327.3885003-1-samuel.holland@sifive.com
Signed-off-by: Paul Walmsley <pjw at kernel.org>
Signed-off-by: Sasha Levin <sashal at 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 at 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
-- 
2.51.0