* [PATCH 1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes
@ 2026-05-09 2:44 George Guo
2026-05-10 15:26 ` Mike Rapoport
0 siblings, 1 reply; 2+ messages in thread
From: George Guo @ 2026-05-09 2:44 UTC (permalink / raw)
To: pasha.tatashin, rppt, pratyush
Cc: graf, jasonmiu, ran.xiaokai, akpm, linux-kernel, kexec, linux-mm,
George Guo, Kexin Liu
From: George Guo <guodongtai@kylinos.cn>
KHO_TREE_MAX_DEPTH is calculated as:
DIV_ROUND_UP(KHO_ORDER_0_LOG2 - KHO_BITMAP_SIZE_LOG2,
KHO_TABLE_SIZE_LOG2) + 1
For systems with 16KB pages (e.g. LoongArch), this gives a depth of 4,
with the top-level shift at bit 39. The order-0 bit sits at bit 50
(KHO_ORDER_0_LOG2 = 64 - PAGE_SHIFT = 50). When inserting or reading
a key, the index extracted at the top level is:
(1 << 50) >> 39 = 2048
2048 is exactly the table size (PAGE_SIZE / sizeof(phys_addr_t) = 2048
for 16KB pages), so it wraps to 0, aliasing the order bit to index 0
and losing it silently.
On the second kernel, kho_radix_decode_key() sees a key without the
order bit, calls fls64() on the wrong bit, computes a wrong order and
thus a garbage physical address. phys_to_page() of that address faults
in kho_preserved_memory_reserve(), causing a kernel panic early in boot.
Fix by adding +1 to the DIV_ROUND_UP numerator so the formula accounts
for the order bit itself, giving depth 5 for 16KB pages. The top-level
shift becomes 50, and (1 << 50) >> 50 = 1, which is nonzero and
unambiguous. For 4KB and 64KB page sizes the depth is unchanged.
Fixes: 3f2ad90060f6 ("kho: adopt radix tree for preserved memory tracking")
Tested-by: Kexin Liu <liukexin@kylinos.cn>
Signed-off-by: George Guo <guodongtai@kylinos.cn>
---
include/linux/kho/abi/kexec_handover.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kho/abi/kexec_handover.h b/include/linux/kho/abi/kexec_handover.h
index 7e847a2339b0..db9bda6dd310 100644
--- a/include/linux/kho/abi/kexec_handover.h
+++ b/include/linux/kho/abi/kexec_handover.h
@@ -274,7 +274,7 @@ enum kho_radix_consts {
* and 1 bitmap level.
*/
KHO_TREE_MAX_DEPTH =
- DIV_ROUND_UP(KHO_ORDER_0_LOG2 - KHO_BITMAP_SIZE_LOG2,
+ DIV_ROUND_UP(KHO_ORDER_0_LOG2 - KHO_BITMAP_SIZE_LOG2 + 1,
KHO_TABLE_SIZE_LOG2) + 1,
};
--
2.25.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH 1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes
2026-05-09 2:44 [PATCH 1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes George Guo
@ 2026-05-10 15:26 ` Mike Rapoport
0 siblings, 0 replies; 2+ messages in thread
From: Mike Rapoport @ 2026-05-10 15:26 UTC (permalink / raw)
To: pasha.tatashin, pratyush, George Guo
Cc: Mike Rapoport, graf, jasonmiu, ran.xiaokai, akpm, linux-kernel,
kexec, linux-mm, George Guo, Kexin Liu
From: Mike Rapoport (Microsoft) <rppt@kernel.org>
On Sat, 09 May 2026 10:44:15 +0800, George Guo wrote:
> KHO_TREE_MAX_DEPTH is calculated as:
>
> DIV_ROUND_UP(KHO_ORDER_0_LOG2 - KHO_BITMAP_SIZE_LOG2,
> KHO_TABLE_SIZE_LOG2) + 1
>
> For systems with 16KB pages (e.g. LoongArch), this gives a depth of 4,
> with the top-level shift at bit 39. The order-0 bit sits at bit 50
> (KHO_ORDER_0_LOG2 = 64 - PAGE_SHIFT = 50). When inserting or reading
> a key, the index extracted at the top level is:
>
> [...]
Applied to fixes branch of liveupdate/linux.git tree, thanks!
[1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes
commit: eaf3933ec58da601cf0008afbcca7cf5433321e8
tree: https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux
branch: fixes
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-10 15:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-09 2:44 [PATCH 1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes George Guo
2026-05-10 15:26 ` Mike Rapoport
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox