linux-kernel - Re: [PATCH] kho: initialize tail pages for higher order folios properly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aEmGMNL9v9djgrGz@kernel.org>
Date: Wed, 11 Jun 2025 16:35:44 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>, Alexander Graf <graf@...zon.com>,
	Changyuan Lyu <changyuanl@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Michal Clapinski <mclapinski@...gle.com>
Subject: Re: [PATCH] kho: initialize tail pages for higher order folios
 properly

On Wed, Jun 11, 2025 at 09:14:55AM -0400, Pasha Tatashin wrote:
> On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav <pratyush@...nel.org> wrote:
> >
> > On Tue, Jun 10 2025, Pasha Tatashin wrote:
> >
> > >> > > I think it should be the other way around, KHO should depend on
> > >> > > !DEFERRED_STRUCT_PAGE_INIT.
> > >> >
> > >> > Agreed, and this is what I first tried, but that does not work, there
> > >> > is some circular dependency breaking the build. If you feel
> > >> > adventurous you can try that :-)
> > >>
> > >> Hmm, weird, worked for me :/
> >
> > Worked for me as well.
> >
> > >
> > > I am super confused, it did not work for me over weekend, and now it
> > > is working. Even `make menuconfig` would not work. Anyways, I will put
> > > it in the appropriate place.
> > >
> > >>
> > >> > > > We will need to teah KHO to work with deferred struct page init. I
> > >> > > > suspect, we could init preserved struct pages and then skip over them
> > >> > > > during deferred init.
> > >> > >
> > >> > > We could, but with that would mean we'll run this before SMP and it's not
> > >> > > desirable. Also, init_deferred_page() for a random page requires
> > >> >
> > >> > We already run KHO init before smp_init:
> > >> > start_kernel() -> mm_core_init() -> kho_memory_init() ->
> > >> > kho_restore_folio() -> struct pages must be already initialized here!
> > >> >
> > >> > While deferred struct pages are initialized:
> > >> > start_kernel() -> rest_init() -> kernel_init() ->
> > >> > kernel_init_freeable() -> page_alloc_init_late() ->
> > >> > deferred_init_memmap()
> > >> >
> > >> > If the number of preserved pages that is needed during early boot is
> > >> > relatively small, that it should not be an issue to pre-initialize
> > >> > struct pages for them before deferred struct pages are initialized. We
> > >> > already pre-initialize some  "struct pages" that are needed during
> > >> > early boot before the reset are initialized, see deferred_grow_zone()
> > >>
> > >> deferred_grow_zone() takes a chunk in the beginning of uninitialized range,
> > >> with kho we are talking about some random pages. If we preinit them early,
> > >> deferred_init_memmap() will overwrite them.
> > >
> > > Yes, this is why I am saying that we would need to skip the KHO
> > > initialized "struct pages" somehow during deferred initialization. If
> > > we create an ordered by PFN list of early-initialized KHO struct
> > > pages, skipping during deferred initialization could be done
> > > efficiently.
> >
> > Or keep things simple and don't use any KHO struct pages during early
> > init. You can access the page itself, just don't use its struct page.
> >
> > Currently the only user of kho_restore_folio() during init is
> > kho_memory_init(). The FDT is accessed by doing
> > phys_to_virt(kho_in.fdt_phys) anyway, so there is really no need for
> > restoring the folio so early. It can be done later, for example when LUO
> > does the finish event, to clean up and free the folio.
> 
> Good suggestion, however, KHO does not have any sophisticated users
> that we are going to be adding as part of the live update work in the
> future: IR, KVM, early VCPU threads, and so on. So, while today, this
> might work, in the future, I am not sure if we should expect struct
> pages are not accessed until after deferred initialization or simply
> fix it once and for all.

KHO already accesses stuct page early and uses page->private for order.
Since preserved memory is reserved in memblock, deferred init of struct
pages won't touch those pages, we just need to make sure they are properly 
initialized at some point. If we don't expect many kho_restore_folio()
before page_alloc_init_late() we can use init_deferred_page() for early
accesses.
 
> Pasha
> 
> >
> > --
> > Regards,
> > Pratyush Yadav

-- 
Sincerely yours,
Mike.