Re: [PATCH v2 2/2] mm/mm_init: decouple page checking and init_on_{alloc, free}

[Joshua Hahn <joshua.hahnjy@gmail.com>]

On Tue, 25 Nov 2025 19:06:53 +0100 Vlastimil Babka <vbabka@suse.cz> wrote:

> On 11/25/25 09:45, Michal Hocko wrote:
> > On Mon 24-11-25 14:54:07, Joshua Hahn wrote:
> >> init_on_alloc and init_on_free protect the kernel by initializing
> >> allocated and freed pages to 0 on allocation time / deletion.
> >> Commit 700d2e9a36b93601270c1e15550acde2521386c5 ("mm, page_alloc: reduce
> >> page alloc/free sanity checks") removed page checking from hot pcp
> >> drain and refill paths, and instead coupled it with CONFIG_DEBUG_VM,
> >> debug_pagealloc, page poisoning, and init_on_{alloc, free}.
> >> 
> >> As the commit suggests, the first three turn the kernel into a debug
> >> kernel, while the last hardens the kernel against leaking sensitive memory.
> >> While enabling page checking is relatively low-cost and tying it
> >> together with page initialization is not unreasonable, it does feel like
> >> a bit of a side-effect, rather than an obvious consequence.
> >> 
> >> With page checking now pulled out as a boot time parameter that can be
> >> set independently, let's decouple page checking and init_on_alloc and
> >> init_on_free.
> >> 
> >> As a direct side effect, systems that have init_on_alloc or init_on_free
> >> will no longer have page checking enabled by default; they will either
> >> have to pass the check_pages boot parameter, build the kernel with
> >> CONFIG_DEBUG_VM, or enable debug_pagealloc / page poisoning.
> > 
> > How come this will not break existing users? What is an actual upside to
> > get for the risk involved?

Hello Michal, Vlastimil

> +Cc hardening people for input if they are fine with the decoupling and if
> docs for hardening recommendations or something similar needs updating

Thank you!

> The upside is mainly reducing the side effects i.e. being more explicit than
> implicit. In practice I'd however assume people running init_on_alloc/free
> and paying the cost also want to do page flags checking anyway. The more
> important patch here is 1/2.

I agree with all of this. Maybe an alternate approach is not to decouple
the flags, but to make their relationship more explicit in Documentation.
Currently, userspace doesn't have much visibility into this relationship, so
an additional line in Documentation/admin-guide/kernel-parameters could
achieve the same desired outcome.

I'll also let the hardning folks comment on this before sending out v3 in case
they have additional requests or ideas for this.

Thank you all for your review!
Joshua