Messages in this thread | | | Date | Wed, 14 Apr 2021 12:01:47 +0200 | From | Oscar Salvador <> | Subject | Re: [PATCH v7 3/7] mm,hugetlb: Clear HPageFreed outside of the lock |
| |
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
| |