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

[Michal Hocko]

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?

-- 
Michal Hocko
SUSE Labs