On 05-09 10:44, George Guo wrote: > From: George Guo <[email protected]> > > 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 <[email protected]> > Signed-off-by: George Guo <[email protected]>
Reviewed-by: Pasha Tatashin <[email protected]> The patch fixes 16K support on ARM64. Pasha
