On Wed, Oct 15, 2025 at 4:19 PM Pasha Tatashin <[email protected]> wrote: > > On Wed, Oct 15, 2025 at 9:05 AM Pratyush Yadav <[email protected]> wrote: > > > > +Cc Marco, Alexander > > > > On Wed, Oct 15 2025, Pasha Tatashin wrote: > > > > > KHO allocates metadata for its preserved memory map using the SLUB > > > allocator via kzalloc(). This metadata is temporary and is used by the > > > next kernel during early boot to find preserved memory. > > > > > > A problem arises when KFENCE is enabled. kzalloc() calls can be > > > randomly intercepted by kfence_alloc(), which services the allocation > > > from a dedicated KFENCE memory pool. This pool is allocated early in > > > boot via memblock. > > > > At some point, we'd probably want to add support for preserving slab > > objects using KHO. That wouldn't work if the objects can land in scratch > > memory. Right now, the kfence pools are allocated right before KHO goes > > out of scratch-only and memblock frees pages to buddy. > > If we do that, most likely we will add a GFP flag that goes with it, > so the slab can use a special pool of pages that are preservable. > Otherwise, we are going to be leaking memory from the old kernel in > the unpreserved parts of the pages. If we do that, kfence can ignore > allocations with that new preservable GFP flag.
I think this is the best way forward. Changing KFENCE to allocate the pool from buddy will make the allocation size less flexible (goodbye, CONFIG_KFENCE_NUM_OBJECTS)
