On Wed, Apr 14, 2021 at 10:28:33AM +0200, Michal Hocko wrote:
> You are right it doesn't do it there. But all struct pages, even those
> that are allocated by the bootmem allocator should initialize its struct
> pages. They would be poisoned otherwise, right? I would have to look at
> the exact code path but IIRC this should be around the time bootmem
> allocator state transitions to the page allocator.
Ok, you are right.
struct pages are initialized a bit earlier through:
start_kernel
setup_arch
paging_init
zone_sizes_init
free_area_init
free_area_init_node
free_area_init_core
memmap_init_zone
memmap_init_range
__init_single_page
While the allocation of bootmem hugetlb happens
start_kernel
parse_args
...
hugepages_setup
...
hugetlb_hstate_alloc_pages
__alloc_bootmem_huge_page
which is after the setup_arch() call.
So by the time we get the page from __alloc_bootmem_huge_page(), fields are
zeroed.
I thought we might get in trouble because memblock_alloc_try_nid_raw() calls
page_init_poison() which poisons the chunk with 0xff,e.g:
[ 1.955471] boot: ffffffffffffffff ffffffffffffffff ffffffffffffffff
ffffffffffffffff
[ 1.955476] boot: ffffffffffffffff ffffffffffffffff ffffffffffffffff
ffffffffffffffff
but it seems that does not the memmap struct page.
I checked, and when we get there in __alloc_bootmem_huge_page, page->private is
still zeroed, so I guess it should be safe to assume that we do not really need
to clear the flag in __prep_new_huge_page() routine?
--
Oscar Salvador
SUSE L3
