Re: [PATCH 4/5] hibernation, KFENCE: explicitly map/unmap KFENCE pages

[Mike Rapoport]

On Wed, Sep 23, 2026 at 12:31:26PM +0200, David Hildenbrand (Arm) wrote:
> On 9/17/26 08:07, Mike Rapoport (Microsoft) wrote:
> > The pages protected by KFENCE are removed from the direct map.
> > 
> > safe_copy_page() temporarily maps and unmaps them using set_direct_map
> > APIs, or, when the stars align, even using debug_pagealloc_map_pages().
> > 
> > Neither of these APIs cares whether it is a KFENCE page and both blindly
> > perform the update of the kernel page table for any non-present page.
> 
> Agreed, we should route this through the actual mechanism that modified the
> directmap in the first place.
> 
> > 
> > Ability to use debug_pagealloc_map_pages() to remap KFENCE pages when both
> > KFENCE and debug_pagealloc are enabled is an amusing coincidence.
> > 
> > But with increasing appetite for using set_direct_map for hardening
> > purposes, it becomes too big of a hammer to enable saving any non-present
> > page in the hibernation image.
> > 
> > Another gotcha is that loongarch that does not have a direct map at all
> > advertises ARCH_HAS_SET_DIRECT_MAP to allow coexistence of KFENCE and
> > hibernation.
> > 
> > Extend KFENCE with a bitmap that tracks which pages are protected and
> > provide kfence_force_mapping() and kfence_restore_mapping() APIs that allow
> > forced mapping and unmapping of KFENCE pages.
> > 
> > Use these APIs in hibernate_{map,unmap}_pages() for KFENCE pages.
> > 
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> > ---
> >  include/linux/kfence.h  | 29 +++++++++++++++++++++++++++
> >  kernel/power/snapshot.c |  7 +++++++
> >  mm/kfence/core.c        | 52 +++++++++++++++++++++++++++++++++++++++++++++++--
> >  3 files changed, 86 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/kfence.h b/include/linux/kfence.h
> > index e5822f6e7f279..33a126cb6d1b7 100644
> > --- a/include/linux/kfence.h
> > +++ b/include/linux/kfence.h
> > @@ -222,6 +222,32 @@ struct kmem_obj_info;
> >  bool __kfence_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab);
> >  #endif
> >  
> > +/**
> > + * kfence_force_mapping() - make sure a KFENCE page is mapped
> > + * @page: page to map
> > + *
> > + * Check whether @page is protected and map it if needed.
> > + *
> > + * Requires: is_kfence_address(page_address(page))
> > + *
> > + * Return:
> > + * * false - failed to map @page
> > + * * true - @page is mapped
> > + */
> > +bool kfence_force_mapping(struct page *page);
> > +
> > +/**
> > + * kfence_restore_mapping() - restore mapping of a KFENCE page
> 
> 
> The name is misleading. You are actually restoring that the page is
> unmapped/protected?
> 
> 	kfence_force_mapping vs. kfence_restore_mapping
> 
> is confusing.
> 
> Can we find a better pair of function names that describe what is actually
> happening?
> 
> Maybe something along the lines of
> 
> 	kfence_prepare_copy_page
> 
> 	kfence_finish_copy_page
> 
> That rather expresses what the caller intends to do.

Naming is hard :-D

I feel that _copy_page() is to vague and adding hibernation there is to
mouthful :(

And these could be used outside of safe_copy_page() someday.

How about 

kfence_set_page_present()
kfence_set_page_default()
 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.