[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aMvnO2FH-cYzNPGl@kernel.org>
Date: Thu, 18 Sep 2025 14:04:27 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Alexander Graf <graf@...zon.com>, Baoquan He <bhe@...hat.com>,
Changyuan Lyu <changyuanl@...gle.com>, Chris Li <chrisl@...nel.org>,
Jason Gunthorpe <jgg@...dia.com>,
Pasha Tatashin <pasha.tatashin@...een.com>,
kexec@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/4] kho: replace kho_preserve_phys() with
kho_preserve_pages()
Hi Pratyush,
On Thu, Sep 18, 2025 at 12:32:08PM +0200, Pratyush Yadav wrote:
> Hi Mike,
>
> On Wed, Sep 17 2025, Mike Rapoport wrote:
>
> > /**
> > - * kho_preserve_phys - preserve a physically contiguous range across kexec.
> > - * @phys: physical address of the range.
> > - * @size: size of the range.
> > + * kho_preserve_pages - preserve contiguous pages across kexec
> > + * @page: first page in the list.
> > + * @nr_pages: number of pages.
> > *
> > - * Instructs KHO to preserve the memory range from @phys to @phys + @size
> > - * across kexec.
> > + * Preserve a contiguous list of order 0 pages. Must be restored using
> > + * kho_restore_page() on each order 0 page.
>
> This is not true. The pages are preserved with the maximum order
> possible.
>
> while (pfn < end_pfn) {
> const unsigned int order =
> min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
>
> err = __kho_preserve_order(track, pfn, order);
> [...]
>
> So four 0-order pages will be preserved as one 2-order page. Restoring
> them as four 0-order pages is wrong. And my proposed patch for checking
> the magic [0] will uncover this exact bug.
>
> I think you should either change the logic to always preserve at order
> 0, or maybe add a kho_restore_pages() that replicates the same order
> calculation.
Heh, it seems I shot myself in the foot when I suggested to move the sanity
checks to kho_restore_page() :-D
We surely don't want to preserve contiguous chunks of order-0 pages as
order 0, so kho_restore_pages() it is.
> [0] https://lore.kernel.org/lkml/20250917125725.665-2-pratyush@kernel.org/
>
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 117d963e677c..6ec3eaa4e8d1 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2516,8 +2516,10 @@ static int reserve_mem_kho_finalize(struct kho_serialization *ser)
> >
> > for (i = 0; i < reserved_mem_count; i++) {
> > struct reserve_mem_table *map = &reserved_mem_table[i];
> > + struct page *page = phys_to_page(map->start);
> > + unsigned int nr_pages = map->size >> PAGE_SHIFT;
> >
> > - err |= kho_preserve_phys(map->start, map->size);
> > + err |= kho_preserve_pages(page, nr_pages);
>
> Unrelated to this patch, but since there is no
> kho_restore_{phys,pages}(), won't the reserve_mem memory end up with
> uninitialized struct pages, since preserved pages are
> memblock_reserved_mark_noinit()?
True, this is something we need to fix.
> That would also be a case for kho_restore_pages() I suppose?
Yes, just need to find the right place to stick it.
We cannot call kho_restore_pages() in reserve_mem_kho_revive() because at
that point there's still no memory map.
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists