linux-kernel - Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1edfe356-8334-42d2-9d68-7c5bf21a01db@kernel.org>
Date: Wed, 14 Jan 2026 13:41:40 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Li Zhe <lizhe.67@...edance.com>, akpm@...ux-foundation.org,
 ankur.a.arora@...cle.com, fvdl@...gle.com, joao.m.martins@...cle.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, mhocko@...e.com,
 muchun.song@...ux.dev, osalvador@...e.de, raghavendra.kt@....com
Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

On 1/14/26 13:33, David Hildenbrand (Red Hat) wrote:
> On 1/14/26 13:11, Mateusz Guzik wrote:
>> On Wed, Jan 14, 2026 at 12:55 PM David Hildenbrand (Red Hat)
>> <david@...nel.org> wrote:
>>> You said "I wonder if implementing hugepage pre-zeroing directly within
>>> the kernel would be a simpler and more direct way to accelerate VM
>>> creation".
>>>
>>> And I agree. But to make that fly (no user space polling interface), I
>>> was wondering whether we could do it like "init_on_free" and let whoever
>>> frees a hugetlb folio just reinitialize it with 0.
>>>
>>> No kernel thread, no user space thread involved.
>>>
>>
>> i don't see how this is supposed to address the stated problem of
>> zeroing being incredibly expensive.
> 
> The price of zeroing has to be paid somewhere.
> 
> Currently it's done at allocation time, we could move it to freeing time.
> 
> That would make application startup faster and application shutdown slower.
> 
> And we're aware that application shutdown can be expensive, which is why
> e.g., QEMU implements an async shutdown operation, where the MM gets
> torn down from another process.

Also, just to mention it, assuming a VM is backed by a hugetlb file, the 
user space thread destroying that file (or parts of it by punshing holes 
and freeing hugetlb folios) would be paying that price.

That could be done whenever there is a CPU to spare to perform some freeing.

But again, I think the main motivation here is "increase application 
startup", not optimize that the zeroing happens at specific points in 
time during system operation (e.g., when idle etc).

-- 
Cheers

David