From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Michal Clapinski <mclapinski@google.com>,
Evangelos Petrongonas <epetron@amazon.de>,
Alexander Graf <graf@amazon.com>,
Samiullah Khawaja <skhawaja@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v7 1/3] kho: make kho_scratch_overlap usable outside debugging
Date: Tue, 07 Apr 2026 16:09:11 +0000 [thread overview]
Message-ID: <2vxzse96ah20.fsf@kernel.org> (raw)
In-Reply-To: <CA+CK2bCSoKGxfV+0QL46p_GqC=rj0YhcvP__bLrM2rVTgTNr=A@mail.gmail.com> (Pasha Tatashin's message of "Tue, 7 Apr 2026 10:18:24 -0400")
On Tue, Apr 07 2026, Pasha Tatashin wrote:
> On Tue, Apr 7, 2026 at 6:55 AM Pratyush Yadav <pratyush@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.
I think you miss the context here. This patchset uses
kho_scratch_overlap() during MM init to set the migrate type of
pageblocks. So it will no longer be gated by
CONFIG_KEXEC_HANDOVER_DEBUG, but by CONFIG_KEXEC_HANDOVER instead. So
there is no need for any #ifdefs. All we need to change is to have the
debug checks gated with a IS_ENABLED(CONFIG_KEXEC_HANDOVER_DEBUG).
So the function stays around, and so do the debug checks. Since core KHO
now uses this function, we just move it out to the main file. And since
kexec_handover_debug.c has nothing else, we can delete it for now.
Anyway, based on the discussion it looks like people want to ask
memblock directly and not use kho_scratch_overlap(), so the next version
might not have this patch at all.
>
> 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
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-04-07 16:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 14:15 [PATCH v7 0/3] kho: add support for deferred struct page init Michal Clapinski
2026-03-17 14:15 ` [PATCH v7 1/3] kho: make kho_scratch_overlap usable outside debugging Michal Clapinski
2026-03-18 9:16 ` Mike Rapoport
2026-04-07 10:55 ` Pratyush Yadav
2026-04-07 14:18 ` Pasha Tatashin
2026-04-07 16:09 ` Pratyush Yadav [this message]
2026-04-07 16:32 ` Pasha Tatashin
2026-03-17 14:15 ` [PATCH v7 2/3] kho: fix deferred init of kho scratch Michal Clapinski
2026-03-17 23:23 ` Vishal Moola (Oracle)
2026-03-18 0:08 ` SeongJae Park
2026-03-18 0:23 ` Andrew Morton
2026-03-18 9:33 ` Mike Rapoport
2026-03-18 10:28 ` Michał Cłapiński
2026-03-18 10:33 ` Michał Cłapiński
2026-03-18 11:02 ` Mike Rapoport
2026-03-18 15:10 ` Zi Yan
2026-03-18 15:18 ` Michał Cłapiński
2026-03-18 15:26 ` Zi Yan
2026-03-18 15:45 ` Michał Cłapiński
2026-03-18 17:08 ` Zi Yan
2026-03-18 17:19 ` Michał Cłapiński
2026-03-18 17:36 ` Zi Yan
2026-03-19 7:54 ` Mike Rapoport
2026-03-19 18:17 ` Michał Cłapiński
2026-03-22 14:45 ` Mike Rapoport
2026-04-07 12:21 ` Pratyush Yadav
2026-04-07 13:21 ` Zi Yan
2026-04-16 9:44 ` Pratyush Yadav
2026-04-09 18:06 ` Mike Rapoport
2026-04-16 9:41 ` Pratyush Yadav
2026-03-17 14:15 ` [PATCH v7 3/3] kho: make preserved pages compatible with deferred struct page init Michal Clapinski
2026-03-17 17:46 ` [PATCH v7 0/3] kho: add support for " Andrew Morton
2026-03-18 9:34 ` Mike Rapoport
2026-03-18 9:18 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2vxzse96ah20.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=epetron@amazon.de \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mclapinski@google.com \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.