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: <mafs0qzzqo2bg.fsf@kernel.org>
Date: Wed, 11 Jun 2025 15:06:11 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Mike Rapoport <rppt@...nel.org>,  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 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.

-- 
Regards,
Pratyush Yadav