Sorry for the late reply. On Mon, May 11 2026, Pratyush Yadav wrote:
> As of now, we only support KHO on x86 and arm64. Are you working on > supporting it for LoongArch? What is your use case? Yes, we are adding KHO support for LoongArch (16KB page size). The LoongArch patches are being prepared separately. This fix is a prerequisite. > Maybe I don't understand the math so well, but I can't see the problem. > ... > level = 4, s = 50, idx = 1 > What am I missing? The issue is that all three operations start the traversal at KHO_TREE_MAX_DEPTH - 1, not KHO_TREE_MAX_DEPTH: kho_radix_add_page() line 180: for (i = KHO_TREE_MAX_DEPTH - 1; i > 0; i--) kho_radix_del_page() line 255: for (i = KHO_TREE_MAX_DEPTH - 1; i > 0; i--) kho_radix_walk_tree() line 356: __kho_radix_walk_tree(..., KHO_TREE_MAX_DEPTH - 1, ...) So with depth=4 the effective top level is 3, not 4. phys_to_page() of that address faults in kho_preserved_memory_reserve(). This is confirmed by a kernel panic on 7.1-rc3 LoongArch (16KB pages) without the fix. With depth=5 the top level is 4 (shift=50): (key >> 50) % 2048 = 1 /* order bit correctly captured */ Signed-off-by: George Guo <[email protected]> Panic log on 7.1-rc3 LoongArch (16KB pages) without the fix: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 00003d3ffe000028, era == 90000000c162f10c, ra == 90000000c162f0f8 [ 0.000000] Oops[#1]: ... [ 0.000000] Call Trace: [ 0.000000] [<90000000c162f10c>] kho_preserved_memory_reserve+0xc4/0xe8 [ 0.000000] [<90000000c0129f88>] __kho_radix_walk_tree+0xf0/0x138 [ 0.000000] [<90000000c0129f10>] __kho_radix_walk_tree+0x78/0x138 [ 0.000000] [<90000000c012b730>] kho_radix_walk_tree+0x88/0xe8 [ 0.000000] [<90000000c162f874>] kho_memory_init+0x220/0x4e4 [ 0.000000] [<90000000c1639b38>] mm_core_init+0x168/0x1a0 [ 0.000000] [<90000000c1620d50>] start_kernel+0x5c4/0x778 [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
