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: <CA+CK2bD3n=JDuSsMGvsyMnVbPhGdhdf6zWFDa3KpzRGEXygdgQ@mail.gmail.com>
Date: Tue, 10 Jun 2025 18:33:38 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Mike Rapoport <rppt@...nel.org>
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

> > > 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 :/

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.

> Anyway, I'm going to look into it, hopefully I'll have something Really
> Soon (tm).

CC:  Michal Clapinski, who was also planning to look into this problem.

Pasha