From: Mike Rapoport <rppt@kernel.org>
To: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <kees@kernel.org>,
Changyuan Lyu <changyuanl@google.com>,
Alexander Graf <graf@amazon.com>, Tony Luck <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Pratyush Yadav <pratyush@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
kexec@lists.infradead.org
Subject: Re: [PATCH v2] memblock: don't allocate new reserve_mem regions on a KHO boot
Date: Thu, 5 Nov 2026 09:59:50 +0200 [thread overview]
Message-ID: <auw3dtAMp4CjNwY2@kernel.org> (raw)
In-Reply-To: <20261104204235.9066-1-azpijr@gmail.com>
On Wed, Nov 04, 2026 at 09:42:17PM +0100, Jose A. Perez de Azpillaga wrote:
> On a KHO boot, a reserve_mem region that can't be revived is allocated
> from KHO_NOPRSRV memory, which includes the bootmem the next kernel
> boots out of. With CONFIG_KEXEC_HANDOVER_DEBUG, preserving the region
> then fails:
>
> WARNING: kernel/liveupdate/kexec_handover.c:1245 at kho_preserve_pages+0x168/0x180
> failed to prepare memblock FDT for KHO: -22
>
> Without it, the next kernel puts its memmap on top of the region and
> the ramoops records in it are lost.
>
> There is no use case for adding regions across a live update, so fail
> instead of allocating, and drop the TODO.
>
> Fixes: f99230780211 ("memblock: add KHO support for reserve_mem")
> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> ---
> Changes in v2:
> - fail on a KHO boot instead of allocating outside bootmem, as agreed
> with Pratyush [1]. this drops v1's patch 1.
> - not an RFC anymore.
> - based on v7.4-rc1.
>
> v1: https://lore.kernel.org/all/20261021211058.83483-3-azpijr@gmail.com/
>
> [1] https://lore.kernel.org/all/2vxzfqxglrg6.fsf@kernel.org/
>
> mm/memblock.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index a450092a80fb..e325e0542c9a 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -2827,7 +2827,16 @@ static int __init reserve_mem(char *p)
> if (reserve_mem_kho_revive(name, size, align))
> return 1;
>
> - /* TODO: Allocation must be outside of KHO_NOPRSRV region */
> + /*
> + * On a KHO boot memblock only allocates from KHO_NOPRSRV memory here,
> + * which includes the bootmem the next kernel boots out of. Only regions
> + * handed over by the previous kernel are supported.
> + */
> + if (is_kho_boot()) {
This breaks memblock tests, please add a stub there.
> + pr_err("reserve_mem: can't allocate \"%s\" on a KHO boot\n", name);
> + return -EOPNOTSUPP;
> + }
> +
> start = memblock_phys_alloc(size, align);
> if (!start) {
> pr_err("reserve_mem: memblock allocation failed\n");
>
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> --
> 2.56.0
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
linux-mm@kvack.org, Kees Cook <kees@kernel.org>,
Changyuan Lyu <changyuanl@google.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Alexander Graf <graf@amazon.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH v2] memblock: don't allocate new reserve_mem regions on a KHO boot
Date: Thu, 5 Nov 2026 09:59:50 +0200 [thread overview]
Message-ID: <auw3dtAMp4CjNwY2@kernel.org> (raw)
In-Reply-To: <20261104204235.9066-1-azpijr@gmail.com>
On Wed, Nov 04, 2026 at 09:42:17PM +0100, Jose A. Perez de Azpillaga wrote:
> On a KHO boot, a reserve_mem region that can't be revived is allocated
> from KHO_NOPRSRV memory, which includes the bootmem the next kernel
> boots out of. With CONFIG_KEXEC_HANDOVER_DEBUG, preserving the region
> then fails:
>
> WARNING: kernel/liveupdate/kexec_handover.c:1245 at kho_preserve_pages+0x168/0x180
> failed to prepare memblock FDT for KHO: -22
>
> Without it, the next kernel puts its memmap on top of the region and
> the ramoops records in it are lost.
>
> There is no use case for adding regions across a live update, so fail
> instead of allocating, and drop the TODO.
>
> Fixes: f99230780211 ("memblock: add KHO support for reserve_mem")
> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> ---
> Changes in v2:
> - fail on a KHO boot instead of allocating outside bootmem, as agreed
> with Pratyush [1]. this drops v1's patch 1.
> - not an RFC anymore.
> - based on v7.4-rc1.
>
> v1: https://lore.kernel.org/all/20261021211058.83483-3-azpijr@gmail.com/
>
> [1] https://lore.kernel.org/all/2vxzfqxglrg6.fsf@kernel.org/
>
> mm/memblock.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index a450092a80fb..e325e0542c9a 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -2827,7 +2827,16 @@ static int __init reserve_mem(char *p)
> if (reserve_mem_kho_revive(name, size, align))
> return 1;
>
> - /* TODO: Allocation must be outside of KHO_NOPRSRV region */
> + /*
> + * On a KHO boot memblock only allocates from KHO_NOPRSRV memory here,
> + * which includes the bootmem the next kernel boots out of. Only regions
> + * handed over by the previous kernel are supported.
> + */
> + if (is_kho_boot()) {
This breaks memblock tests, please add a stub there.
> + pr_err("reserve_mem: can't allocate \"%s\" on a KHO boot\n", name);
> + return -EOPNOTSUPP;
> + }
> +
> start = memblock_phys_alloc(size, align);
> if (!start) {
> pr_err("reserve_mem: memblock allocation failed\n");
>
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> --
> 2.56.0
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-11-05 8:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 20:42 [PATCH v2] memblock: don't allocate new reserve_mem regions on a KHO boot Jose A. Perez de Azpillaga
2026-11-04 20:42 ` Jose A. Perez de Azpillaga
2026-11-05 2:28 ` Pasha Tatashin
2026-11-05 2:28 ` Pasha Tatashin
2026-11-05 7:59 ` Mike Rapoport [this message]
2026-11-05 7:59 ` Mike Rapoport
2026-11-05 11:56 ` Jose A. Perez de Azpillaga
2026-11-05 11:56 ` Jose A. Perez de Azpillaga
2026-11-05 20:44 ` sashiko-bot
2026-11-05 20:44 ` sashiko-bot
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=auw3dtAMp4CjNwY2@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=azpijr@gmail.com \
--cc=changyuanl@google.com \
--cc=gpiccoli@igalia.com \
--cc=graf@amazon.com \
--cc=kees@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=tony.luck@intel.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.