kernel/liveupdate/kexec_handover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Before commit fa759cd75bce5 ("kho: allocate metadata directly from the
buddy allocator"), the chunks were allocated from the slab allocator
using kzalloc(). Those were rightly freed using kfree().
When the commit switched to using the buddy allocator directly, it
missed updating kho_mem_ser_free() to use free_page() instead of
kfree().
Fixes: fa759cd75bce5 ("kho: allocate metadata directly from the buddy allocator")
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
---
Notes:
Commit 73976b0f7cefe ("kho: remove abort functionality and support state
refresh") made this bug easier to trigger by providing a deterministic
method to trigger freeing of the chunks.
kernel/liveupdate/kexec_handover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 515339fa526e0..6497fe68c2d24 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -360,7 +360,7 @@ static void kho_mem_ser_free(struct khoser_mem_chunk *first_chunk)
struct khoser_mem_chunk *tmp = chunk;
chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
- kfree(tmp);
+ free_page((unsigned long)tmp);
}
}
base-commit: f0bfdc2b69f5c600b88ee484c01b213712c63d94
prerequisite-patch-id: f54df1de9bdcb4fe396940cdcc578f5adcc9397c
prerequisite-patch-id: 800ec910c37120fd77aff1fad8ec10daaeaeddb1
--
2.47.3
… > When the commit switched to using the buddy allocator directly, it > missed updating kho_mem_ser_free() to use free_page() instead of > kfree(). Would another imperative wording become helpful for an improved change description? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.18-rc6#n94 Regards, Markus
On Wed, Nov 19 2025, Markus Elfring wrote:
> …
>> When the commit switched to using the buddy allocator directly, it
>> missed updating kho_mem_ser_free() to use free_page() instead of
>> kfree().
>
> Would another imperative wording become helpful for an improved change description?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.18-rc6#n94
"the commit" here refers to the commit fa759cd75bce5 ("kho: allocate
metadata directly from the buddy allocator"), not "this commit"/"this
patch". I figured that can be understood from the context and I won't
need to spell the whole thing out again.
I don't understand the technicalities of the English grammar so well,
but IIUC imperative mood is used in sentences that give a command. This
paragraph talks about a past event.
Anyway, if you have something better, happy to take suggestions.
--
Regards,
Pratyush Yadav
> Anyway, if you have something better, happy to take suggestions. You provided a reasonable change introduction (and justification). How do you think about to add a wording like “Thus use an appropriate macro call.”? Would it be helpful to mention the affected function implementation also in the summary phrase? Regards, Markus
On Tue, Nov 18, 2025 at 07:22:16PM +0100, Pratyush Yadav wrote:
> Before commit fa759cd75bce5 ("kho: allocate metadata directly from the
> buddy allocator"), the chunks were allocated from the slab allocator
> using kzalloc(). Those were rightly freed using kfree().
>
> When the commit switched to using the buddy allocator directly, it
> missed updating kho_mem_ser_free() to use free_page() instead of
> kfree().
>
> Fixes: fa759cd75bce5 ("kho: allocate metadata directly from the buddy allocator")
> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>
> Notes:
> Commit 73976b0f7cefe ("kho: remove abort functionality and support state
> refresh") made this bug easier to trigger by providing a deterministic
> method to trigger freeing of the chunks.
>
> kernel/liveupdate/kexec_handover.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 515339fa526e0..6497fe68c2d24 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -360,7 +360,7 @@ static void kho_mem_ser_free(struct khoser_mem_chunk *first_chunk)
> struct khoser_mem_chunk *tmp = chunk;
>
> chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
> - kfree(tmp);
> + free_page((unsigned long)tmp);
> }
> }
>
>
> base-commit: f0bfdc2b69f5c600b88ee484c01b213712c63d94
> prerequisite-patch-id: f54df1de9bdcb4fe396940cdcc578f5adcc9397c
> prerequisite-patch-id: 800ec910c37120fd77aff1fad8ec10daaeaeddb1
> --
> 2.47.3
>
--
Sincerely yours,
Mike.
On Tue, Nov 18, 2025 at 1:22 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> Before commit fa759cd75bce5 ("kho: allocate metadata directly from the
> buddy allocator"), the chunks were allocated from the slab allocator
> using kzalloc(). Those were rightly freed using kfree().
>
> When the commit switched to using the buddy allocator directly, it
> missed updating kho_mem_ser_free() to use free_page() instead of
> kfree().
>
> Fixes: fa759cd75bce5 ("kho: allocate metadata directly from the buddy allocator")
> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Thank you for finding and fixing this issue.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
© 2016 - 2025 Red Hat, Inc.