linux-kernel - Re: [RFC PATCH 04/10] liveupdate: flb: allow getting FLB data in early boot

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] [day] [month] [year] [list]

Message-ID: <86o6nqd0m4.fsf@kernel.org>
Date: Mon, 22 Dec 2025 23:58:43 +0900
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Mike Rapoport <rppt@...nel.org>,
  Andrew Morton <akpm@...ux-foundation.org>,  David Hildenbrand
 <david@...nel.org>,  Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,  "Liam
 R. Howlett" <Liam.Howlett@...cle.com>,  Vlastimil Babka <vbabka@...e.cz>,
  Suren Baghdasaryan <surenb@...gle.com>,  Michal Hocko <mhocko@...e.com>,
  Jonathan Corbet <corbet@....net>,  Thomas Gleixner <tglx@...utronix.de>,
  Ingo Molnar <mingo@...hat.com>,  Borislav Petkov <bp@...en8.de>,  Dave
 Hansen <dave.hansen@...ux.intel.com>,  x86@...nel.org,  "H. Peter Anvin"
 <hpa@...or.com>,  Muchun Song <muchun.song@...ux.dev>,  Oscar Salvador
 <osalvador@...e.de>,  Alexander Graf <graf@...zon.com>,  David Matlack
 <dmatlack@...gle.com>,  David Rientjes <rientjes@...gle.com>,  Jason
 Gunthorpe <jgg@...dia.com>,  Samiullah Khawaja <skhawaja@...gle.com>,
  Vipin Sharma <vipinsh@...gle.com>,  Zhu Yanjun <yanjun.zhu@...ux.dev>,
  linux-kernel@...r.kernel.org,  linux-mm@...ck.org,
  linux-doc@...r.kernel.org,  kexec@...ts.infradead.org
Subject: Re: [RFC PATCH 04/10] liveupdate: flb: allow getting FLB data in
 early boot

On Sat, Dec 20 2025, Pasha Tatashin wrote:

>> > [Follow-up from LPC discussion]
>> >
>> > This patch is not needed, you can use liveupdate_flb_get_incoming()
>> > directly in early boot. The main concern is that we take mutex in that
>> > function, but that I think is safe. The might_sleep() has the proper
>> > handling to be called early in boot, it has "system_state ==
>> > SYSTEM_BOOTING" check to silence warning during boot.
>>
>> Right. I will give it a try. For hugetlb, this works fine since it
>> doesn't really need to do much in FLB retrieve anyway, it just needs to
>> parse some data structures.
>>
>> If other subsystems end up needing a two-part retrieve, one in early
>> boot and one later, then I think it would be a good idea to model that
>> properly instead of leaving it up to the subsystem to manage it.
>>
>> Anyway, that isn't a real problem today so let's look at it when it does
>> show up.
>
> FLB has exactly one .retrieve() lifecycle event. Once called, the data
> is considered fully available and cached in private->incoming.obj.
>
> If a subsystem has a requirement where it needs a specific state
> available very early and other state available much later, the clean
> solution is simply to register two separate FLBs.

Hmm, that can work too. Anyway, let's figure that out when there is a
real use case. For now, the current FLB design works fine.

-- 
Regards,
Pratyush Yadav