[PATCH 0/2] kho: misc fixes

[PATCH 0/2] kho: misc fixes

[Pratyush Yadav]

This series has a couple of misc fixes for KHO I discovered during code
review and testing.

The series is based on top of [0] which has another fix for the function
touched by patch 1. I spotted these two after sending the patch. If that
one needs a reroll, I can combine the three into a series.

[0] https://lore.kernel.org/linux-mm/20251103110159.8399-1-pratyush@kernel.org/

Pratyush Yadav (2):
  kho: fix unpreservation of higher-order vmalloc preservations
  kho: warn and exit when unpreserved page wasn't preserved

 kernel/kexec_handover.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)


base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa
prerequisite-patch-id: fce7dcea45c85bac06a559d06f038e9c0cb38b17
-- 
2.47.3

[PATCH 1/2] kho: fix unpreservation of higher-order vmalloc preservations

[Pratyush Yadav]

kho_vmalloc_unpreserve_chunk() calls __kho_unpreserve() with end_pfn as
pfn + 1. This happens to work for 0-order pages, but leaks higher order
pages.

For example, say order 2 pages back the allocation. During preservation,
they get preserved in the order 2 bitmaps, but
kho_vmalloc_unpreserve_chunk() would try to unpreserve them from the
order 0 bitmaps, which should not have these bits set anyway, leaving
the order 2 bitmaps untouched. This results in the pages being carried
over to the next kernel. Nothing will free those pages in the next boot,
leaking them.

Fix this by taking the order into account when calculating the end PFN
for __kho_unpreserve().

Fixes: a667300bd53f2 ("kho: add support for preserving vmalloc allocations")
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
---

Notes:
    When Pasha's patch [0] to add kho_unpreserve_pages() is merged, maybe it
    would be a better idea to use kho_unpreserve_pages() here? But that is
    something for later I suppose.
    
    [0] https://lore.kernel.org/linux-mm/20251101142325.1326536-4-pasha.tatashin@soleen.com/

 kernel/kexec_handover.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
index cc5aaa738bc50..c2bcbb10918ce 100644
--- a/kernel/kexec_handover.c
+++ b/kernel/kexec_handover.c
@@ -862,7 +862,8 @@ static struct kho_vmalloc_chunk *new_vmalloc_chunk(struct kho_vmalloc_chunk *cur
 	return NULL;
 }
 
-static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk)
+static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk,
+					 unsigned short order)
 {
 	struct kho_mem_track *track = &kho_out.ser.track;
 	unsigned long pfn = PHYS_PFN(virt_to_phys(chunk));
@@ -871,7 +872,7 @@ static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk)
 
 	for (int i = 0; i < ARRAY_SIZE(chunk->phys) && chunk->phys[i]; i++) {
 		pfn = PHYS_PFN(chunk->phys[i]);
-		__kho_unpreserve(track, pfn, pfn + 1);
+		__kho_unpreserve(track, pfn, pfn + (1 << order));
 	}
 }
 
@@ -882,7 +883,7 @@ static void kho_vmalloc_free_chunks(struct kho_vmalloc *kho_vmalloc)
 	while (chunk) {
 		struct kho_vmalloc_chunk *tmp = chunk;
 
-		kho_vmalloc_unpreserve_chunk(chunk);
+		kho_vmalloc_unpreserve_chunk(chunk, kho_vmalloc->order);
 
 		chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
 		free_page((unsigned long)tmp);
-- 
2.47.3

Re: [PATCH 1/2] kho: fix unpreservation of higher-order vmalloc preservations

[Mike Rapoport]

On Mon, Nov 03, 2025 at 07:02:31PM +0100, Pratyush Yadav wrote:
> kho_vmalloc_unpreserve_chunk() calls __kho_unpreserve() with end_pfn as
> pfn + 1. This happens to work for 0-order pages, but leaks higher order
> pages.
> 
> For example, say order 2 pages back the allocation. During preservation,
> they get preserved in the order 2 bitmaps, but
> kho_vmalloc_unpreserve_chunk() would try to unpreserve them from the
> order 0 bitmaps, which should not have these bits set anyway, leaving
> the order 2 bitmaps untouched. This results in the pages being carried
> over to the next kernel. Nothing will free those pages in the next boot,
> leaking them.
> 
> Fix this by taking the order into account when calculating the end PFN
> for __kho_unpreserve().
> 
> Fixes: a667300bd53f2 ("kho: add support for preserving vmalloc allocations")
> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Notes:
>     When Pasha's patch [0] to add kho_unpreserve_pages() is merged, maybe it
>     would be a better idea to use kho_unpreserve_pages() here? But that is
>     something for later I suppose.
>     
>     [0] https://lore.kernel.org/linux-mm/20251101142325.1326536-4-pasha.tatashin@soleen.com/
> 
>  kernel/kexec_handover.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
> index cc5aaa738bc50..c2bcbb10918ce 100644
> --- a/kernel/kexec_handover.c
> +++ b/kernel/kexec_handover.c
> @@ -862,7 +862,8 @@ static struct kho_vmalloc_chunk *new_vmalloc_chunk(struct kho_vmalloc_chunk *cur
>  	return NULL;
>  }
>  
> -static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk)
> +static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk,
> +					 unsigned short order)
>  {
>  	struct kho_mem_track *track = &kho_out.ser.track;
>  	unsigned long pfn = PHYS_PFN(virt_to_phys(chunk));
> @@ -871,7 +872,7 @@ static void kho_vmalloc_unpreserve_chunk(struct kho_vmalloc_chunk *chunk)
>  
>  	for (int i = 0; i < ARRAY_SIZE(chunk->phys) && chunk->phys[i]; i++) {
>  		pfn = PHYS_PFN(chunk->phys[i]);
> -		__kho_unpreserve(track, pfn, pfn + 1);
> +		__kho_unpreserve(track, pfn, pfn + (1 << order));
>  	}
>  }
>  
> @@ -882,7 +883,7 @@ static void kho_vmalloc_free_chunks(struct kho_vmalloc *kho_vmalloc)
>  	while (chunk) {
>  		struct kho_vmalloc_chunk *tmp = chunk;
>  
> -		kho_vmalloc_unpreserve_chunk(chunk);
> +		kho_vmalloc_unpreserve_chunk(chunk, kho_vmalloc->order);
>  
>  		chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
>  		free_page((unsigned long)tmp);
> -- 
> 2.47.3
> 

-- 
Sincerely yours,
Mike.

[PATCH 2/2] kho: warn and exit when unpreserved page wasn't preserved

[Pratyush Yadav]

Calling __kho_unpreserve() on a pair of (pfn, end_pfn) that wasn't
preserved is a bug. Currently, if that is done, the physxa or bits can
be NULL. This results in a soft lockup since a NULL physxa or bits
results in redoing the loop without ever making any progress.

Return when physxa or bits are not found, but WARN first to loudly
indicate invalid behaviour.

Fixes: fc33e4b44b271 ("kexec: enable KHO support for memory preservation")
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
---
 kernel/kexec_handover.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
index c2bcbb10918ce..e5fd833726226 100644
--- a/kernel/kexec_handover.c
+++ b/kernel/kexec_handover.c
@@ -167,12 +167,12 @@ static void __kho_unpreserve(struct kho_mem_track *track, unsigned long pfn,
 		const unsigned long pfn_high = pfn >> order;
 
 		physxa = xa_load(&track->orders, order);
-		if (!physxa)
-			continue;
+		if (WARN_ON_ONCE(!physxa))
+			return;
 
 		bits = xa_load(&physxa->phys_bits, pfn_high / PRESERVE_BITS);
-		if (!bits)
-			continue;
+		if (WARN_ON_ONCE(!bits))
+			return;
 
 		clear_bit(pfn_high % PRESERVE_BITS, bits->preserve);
 
-- 
2.47.3

Re: [PATCH 2/2] kho: warn and exit when unpreserved page wasn't preserved

[Mike Rapoport]

On Mon, Nov 03, 2025 at 07:02:32PM +0100, Pratyush Yadav wrote:
> Calling __kho_unpreserve() on a pair of (pfn, end_pfn) that wasn't
> preserved is a bug. Currently, if that is done, the physxa or bits can
> be NULL. This results in a soft lockup since a NULL physxa or bits
> results in redoing the loop without ever making any progress.
> 
> Return when physxa or bits are not found, but WARN first to loudly
> indicate invalid behaviour.
> 
> Fixes: fc33e4b44b271 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  kernel/kexec_handover.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
> index c2bcbb10918ce..e5fd833726226 100644
> --- a/kernel/kexec_handover.c
> +++ b/kernel/kexec_handover.c
> @@ -167,12 +167,12 @@ static void __kho_unpreserve(struct kho_mem_track *track, unsigned long pfn,
>  		const unsigned long pfn_high = pfn >> order;
>  
>  		physxa = xa_load(&track->orders, order);
> -		if (!physxa)
> -			continue;
> +		if (WARN_ON_ONCE(!physxa))
> +			return;
>  
>  		bits = xa_load(&physxa->phys_bits, pfn_high / PRESERVE_BITS);
> -		if (!bits)
> -			continue;
> +		if (WARN_ON_ONCE(!bits))
> +			return;
>  
>  		clear_bit(pfn_high % PRESERVE_BITS, bits->preserve);
>  
> -- 
> 2.47.3
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 0/2] kho: misc fixes

[Andrew Morton]

On Mon,  3 Nov 2025 19:02:30 +0100 Pratyush Yadav <pratyush@kernel.org> wrote:

> This series has a couple of misc fixes for KHO I discovered during code
> review and testing.
> 
> The series is based on top of [0] which has another fix for the function
> touched by patch 1. I spotted these two after sending the patch. If that
> one needs a reroll, I can combine the three into a series.
>

Things appear to be misordered here.

[1/2] "kho: fix unpreservation of higher-order vmalloc preservations"
	fixes a667300bd53f2, so it's wanted in 6.18-rcX

[2/2] "kho: warn and exit when unpreserved page wasn't preserved"
	fixes fc33e4b44b271, so it's wanted in 6.16+

So can we please have [2/2] as a standalone fix against latest -linus,
with a cc:stable?

And then [1/2] as a standalone fix against latest -linus without a
cc:stable.


Once I have those merged up we can then take a look at what to do about
the 6.19 material which is presently queued in mm-unstable.

Thanks.

Re: [PATCH 0/2] kho: misc fixes

[Andrew Morton]

On Mon, 3 Nov 2025 16:20:20 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon,  3 Nov 2025 19:02:30 +0100 Pratyush Yadav <pratyush@kernel.org> wrote:
> 
> > This series has a couple of misc fixes for KHO I discovered during code
> > review and testing.
> > 
> > The series is based on top of [0] which has another fix for the function
> > touched by patch 1. I spotted these two after sending the patch. If that
> > one needs a reroll, I can combine the three into a series.
> >
> 
> Things appear to be misordered here.
> 
> [1/2] "kho: fix unpreservation of higher-order vmalloc preservations"
> 	fixes a667300bd53f2, so it's wanted in 6.18-rcX
> 
> [2/2] "kho: warn and exit when unpreserved page wasn't preserved"
> 	fixes fc33e4b44b271, so it's wanted in 6.16+
> 
> So can we please have [2/2] as a standalone fix against latest -linus,
> with a cc:stable?
> 
> And then [1/2] as a standalone fix against latest -linus without a
> cc:stable.
> 

OK, I think I figured it out.

In mm-hotfixes-unstable I have

kho-fix-out-of-bounds-access-of-vmalloc-chunk.patch
kho-fix-unpreservation-of-higher-order-vmalloc-preservations.patch
kho-warn-and-exit-when-unpreserved-page-wasnt-preserved.patch

The first two are applicable to 6.18-rcX and the third is applicable to
6.18-rcX, with a cc:stable for backporting.

Re: [PATCH 0/2] kho: misc fixes

[Pratyush Yadav]

On Mon, Nov 03 2025, Andrew Morton wrote:

> On Mon, 3 Nov 2025 16:20:20 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> On Mon,  3 Nov 2025 19:02:30 +0100 Pratyush Yadav <pratyush@kernel.org> wrote:
>> 
>> > This series has a couple of misc fixes for KHO I discovered during code
>> > review and testing.
>> > 
>> > The series is based on top of [0] which has another fix for the function
>> > touched by patch 1. I spotted these two after sending the patch. If that
>> > one needs a reroll, I can combine the three into a series.
>> >
>> 
>> Things appear to be misordered here.
>> 
>> [1/2] "kho: fix unpreservation of higher-order vmalloc preservations"
>> 	fixes a667300bd53f2, so it's wanted in 6.18-rcX
>> 
>> [2/2] "kho: warn and exit when unpreserved page wasn't preserved"
>> 	fixes fc33e4b44b271, so it's wanted in 6.16+
>> 
>> So can we please have [2/2] as a standalone fix against latest -linus,
>> with a cc:stable?
>> 
>> And then [1/2] as a standalone fix against latest -linus without a
>> cc:stable.
>> 
>
> OK, I think I figured it out.
>
> In mm-hotfixes-unstable I have
>
> kho-fix-out-of-bounds-access-of-vmalloc-chunk.patch
> kho-fix-unpreservation-of-higher-order-vmalloc-preservations.patch
> kho-warn-and-exit-when-unpreserved-page-wasnt-preserved.patch
>
> The first two are applicable to 6.18-rcX and the third is applicable to
> 6.18-rcX, with a cc:stable for backporting.

Right. Sorry for the confusion. I see that on mm-hotfixes-unstable you
already updated the third patch with Cc: stable. Thanks.

-- 
Regards,
Pratyush Yadav