From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: akpm@linux-foundation.org, brauner@kernel.org, corbet@lwn.net,
graf@amazon.com, jgg@ziepe.ca, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
masahiroy@kernel.org, ojeda@kernel.org, pratyush@kernel.org,
rdunlap@infradead.org, rppt@kernel.org, tj@kernel.org,
jasonmiu@google.com, dmatlack@google.com, skhawaja@google.com
Subject: Re: [PATCH v3 1/3] liveupdate: kho: warn and fail on metadata or preserved memory in scratch area
Date: Wed, 22 Oct 2025 12:22:37 +0200 [thread overview]
Message-ID: <mafs0v7k7fd76.fsf@kernel.org> (raw)
In-Reply-To: <20251021000852.2924827-2-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Mon, 20 Oct 2025 20:08:50 -0400")
On Mon, Oct 20 2025, Pasha Tatashin wrote:
> It is invalid for KHO metadata or preserved memory regions to be located
> within the KHO scratch area, as this area is overwritten when the next
> kernel is loaded, and used early in boot by the next kernel. This can
> lead to memory corruption.
>
> Adds checks to kho_preserve_* and KHO's internal metadata allocators
> (xa_load_or_alloc, new_chunk) to verify that the physical address of the
> memory does not overlap with any defined scratch region. If an overlap
> is detected, the operation will fail and a WARN_ON is triggered. To
> avoid performance overhead in production kernels, these checks are
> enabled only when CONFIG_KEXEC_HANDOVER_DEBUG is selected.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
[...]
> @@ -133,26 +135,26 @@ static struct kho_out kho_out = {
>
> static void *xa_load_or_alloc(struct xarray *xa, unsigned long index, size_t sz)
> {
> - void *elm, *res;
> + void *res = xa_load(xa, index);
>
> - elm = xa_load(xa, index);
> - if (elm)
> - return elm;
> + if (res)
> + return res;
> +
> + void *elm __free(kfree) = kzalloc(sz, GFP_KERNEL);
>
> - elm = kzalloc(sz, GFP_KERNEL);
> if (!elm)
> return ERR_PTR(-ENOMEM);
>
> + if (WARN_ON(kho_scratch_overlap(virt_to_phys(elm), sz)))
> + return ERR_PTR(-EINVAL);
> +
> res = xa_cmpxchg(xa, index, NULL, elm, GFP_KERNEL);
> if (xa_is_err(res))
> - res = ERR_PTR(xa_err(res));
> -
> - if (res) {
> - kfree(elm);
> + return ERR_PTR(xa_err(res));
> + else if (res)
> return res;
> - }
>
> - return elm;
> + return no_free_ptr(elm);
Super small nit: there exists return_ptr(p) which is a tiny bit neater
IMO but certainly not worth doing a new revision over. So,
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-10-22 10:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 0:08 [PATCH v3 0/3] KHO: kfence + KHO memory corruption fix Pasha Tatashin
2025-10-21 0:08 ` [PATCH v3 1/3] liveupdate: kho: warn and fail on metadata or preserved memory in scratch area Pasha Tatashin
2025-10-22 10:22 ` Pratyush Yadav [this message]
2025-10-27 22:29 ` David Matlack
2025-10-28 0:01 ` Pasha Tatashin
2025-10-29 16:09 ` Jason Gunthorpe
2025-10-29 8:48 ` Mike Rapoport
2025-10-29 22:22 ` Pasha Tatashin
2025-10-29 22:35 ` Andrew Morton
2025-10-21 0:08 ` [PATCH v3 2/3] liveupdate: kho: Increase metadata bitmap size to PAGE_SIZE Pasha Tatashin
2025-10-22 10:25 ` Pratyush Yadav
2025-10-27 22:44 ` David Matlack
2025-10-27 22:56 ` David Matlack
2025-10-27 23:01 ` David Matlack
2025-10-28 0:03 ` Pasha Tatashin
2025-10-21 0:08 ` [PATCH v3 3/3] liveupdate: kho: allocate metadata directly from the buddy allocator Pasha Tatashin
2025-10-27 23:04 ` David Matlack
2025-10-28 0:03 ` Pasha Tatashin
2025-10-21 6:00 ` [PATCH v3 0/3] KHO: kfence + KHO memory corruption fix Mike Rapoport
2025-10-21 16:04 ` Pasha Tatashin
2025-10-21 20:53 ` Andrew Morton
2025-10-22 0:15 ` Pasha Tatashin
2025-10-22 5:48 ` Mike Rapoport
2025-10-22 18:24 ` Andrew Morton
2025-10-23 2:45 ` Andrew Morton
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=mafs0v7k7fd76.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=ojeda@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
--cc=tj@kernel.org \
/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.