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: <86wm2hj0ky.fsf@kernel.org>
Date: Sat, 20 Dec 2025 12:26:05 +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 Thu, Dec 18 2025, Pasha Tatashin wrote:

> On Sat, Dec 6, 2025 at 6:03 PM Pratyush Yadav <pratyush@...nel.org> wrote:
>>
>> To support hugepage preservation using LUO, the hugetlb subsystem needs
>> to get liveupdate data when it allocates the hugepages to find out how
>> many pages are coming from live update. This data is preserved via LUO
>> FLB.
>>
>> Since gigantic hugepage allocations happen before LUO (and much of the
>> rest of the system) is initialized, the usual
>> liveupdate_flb_get_incoming() can not work.
>>
>> Add a read-only variant that fetches the FLB data but does not trigger
>> its retrieve or do any locking or reference counting. It is the caller's
>> responsibility to make sure there are no side effects of using this data
>> to the proper retrieve call that would happen later.
>>
>> Refactor the logic to find the right FLB in the serialized data in a
>> helper that can be used from both luo_flb_retrieve_one() (called from
>> luo_flb_get_incoming()), and from luo_flb_get_incoming_early().
>>
>> Signed-off-by: Pratyush Yadav <pratyush@...nel.org>
>> ---
>>  include/linux/liveupdate.h  |  6 ++++
>>  kernel/liveupdate/luo_flb.c | 69 +++++++++++++++++++++++++++++--------
>>  2 files changed, 60 insertions(+), 15 deletions(-)
>>
>> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
>> index 78e8c529e4e7..39b429d2c62c 100644
>> --- a/include/linux/liveupdate.h
>> +++ b/include/linux/liveupdate.h
>> @@ -232,6 +232,7 @@ int liveupdate_unregister_flb(struct liveupdate_file_handler *fh,
>>
>>  int liveupdate_flb_get_incoming(struct liveupdate_flb *flb, void **objp);
>>  int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
>> +int liveupdate_flb_incoming_early(struct liveupdate_flb *flb, u64 *datap);
>
> Hi Pratyush,
>
> [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.

-- 
Regards,
Pratyush Yadav