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
