[PATCH v7 1/3] kho: make kho_scratch_overlap usable outside debugging

[Pasha Tatashin]

On Tue, Apr 7, 2026 at 6:55 AM Pratyush Yadav <pratyush at kernel.org> wrote:
>
> On Wed, Mar 18 2026, Mike Rapoport wrote:
>
> > Hi Michal,
> >
> > On Tue, Mar 17, 2026 at 03:15:32PM +0100, Michal Clapinski wrote:
> >> Also return false if kho_scratch is NULL.
> >>
> [...]
> >> diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> >> index d2f779cbe279..dc352839ccf0 100644
> >> --- a/kernel/liveupdate/Makefile
> >> +++ b/kernel/liveupdate/Makefile
> >> @@ -7,7 +7,6 @@ luo-y :=                                                             \
> >>              luo_session.o
> >>
> >>  obj-$(CONFIG_KEXEC_HANDOVER)                += kexec_handover.o
> >> -obj-$(CONFIG_KEXEC_HANDOVER_DEBUG)  += kexec_handover_debug.o
> >>  obj-$(CONFIG_KEXEC_HANDOVER_DEBUGFS)        += kexec_handover_debugfs.o
> >>
> >>  obj-$(CONFIG_LIVEUPDATE)            += luo.o
> >> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> >> index 532f455c5d4f..c9b982372d6e 100644
> >> --- a/kernel/liveupdate/kexec_handover.c
> >> +++ b/kernel/liveupdate/kexec_handover.c
> >> @@ -820,7 +820,8 @@ int kho_preserve_folio(struct folio *folio)
> >>      const unsigned long pfn = folio_pfn(folio);
> >>      const unsigned int order = folio_order(folio);
> >>
> >> -    if (WARN_ON(kho_scratch_overlap(pfn << PAGE_SHIFT, PAGE_SIZE << order)))
> >> +    if (WARN_ON(kho_scratch_overlap_debug(pfn << PAGE_SHIFT,
> >> +                                          PAGE_SIZE << order)))
> >
> > Can't say I'm fond of kho_scratch_overlap_debug(). How about we make it
> >
> >       if (IS_ENABLED(CONFIG_KEXEC_HANDOVER_DEBUG) &&
> >           WARN_ON(kho_scratch_overlap(...))
>
> +1. And we can get rid of kexec_handover_debug.c, for now at least. We
> can add it back when we have something else to put in there.

Are you proposing moving kho_scratch_overlap() into kexec_handover.c?
That would make it uglier to have #ifdefs in the C file. If you mean
removing this function entirely, I think that is too dangerous because
we have already had a memory corruption issue [1] that was challenging
to root cause, and having this simple check prevents this from
occurring going forward. The problem is that changes to defences such
as kfence, kasan, and asi are happening outside of the core KHO code,
and it is very easy to miss when something unexpectedly causes a
preservation from the scratch area, as we have seen this with kfence.
Worst of all, some of those mitigations use randomized or sampling
approaches and might not be reproducible on every try, so having a
CONFIG that tests it every time in a debug build is the only solid
defense against that.

Pasha

[1] https://lore.kernel.org/all/20251021000852.2924827-1-pasha.tatashin@soleen.com

>
> >
> >>              return -EINVAL;
> >>
> >>      return kho_radix_add_page(tree, pfn, order);
> [...]
>
> --
> Regards,
> Pratyush Yadav