[PATCH] kho: free chunks using free_page() instead of kfree()

[PATCH] kho: free chunks using free_page() instead of kfree()

[Pratyush Yadav]

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

Re: [PATCH] kho: free chunks using free_page() instead of kfree()

[Pasha Tatashin]

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>

Re: [PATCH] kho: free chunks using free_page() instead of kfree()

[Mike Rapoport]

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.

Re: [PATCH] kho: free chunks using free_page() instead of kfree()

[Markus Elfring]

…
> 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

Re: [PATCH] kho: free chunks using free_page() instead of kfree()

[Pratyush Yadav]

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

Re: kho: free chunks using free_page() instead of kfree()

[Markus Elfring]

> 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