Re: [PATCH v1 1/1] mm: buddy page accessed before initialized

[Pavel Tatashin]

> Why cannot we do something similar to the optimized struct page
> initialization and write 8B at the time and fill up the size unaligned
> chunk in 1B?

I do not think this is a good idea: memset() on SPARC is slow for
small sizes, this is why we ended up using stores, but thats not the
case on x86 where memset() is well optimized for small sizes. So, I
believe we will see regressions. But even without the regressions
there are several reasons why I think this is not a good idea:
1. struct page size vary depending on configs. So, in order to create
a pattern that looks like a valid struct page, we would need to figure
out what is our struct page size.
2. memblock allocator is totally independent from struct pages, it is
going to be strange to add this dependency. The allocatoted memory is
also used for page tables, and kasan, so we do not really know where
the pattern should start from the allocator point of view.
3. It is going to be too easy to break that pattern if something
changes or shifts: struct page changes, vmemmap allocations change or
anything else.

Overall, I think now we have a good coverage now: CONFIG_DEBUG_VM
option tests for totally invalid struct pages, and kexec tests for
struct pages that look like valid ones, but they are invalid because
from the previous instance of kernel.

Pasha