On Thu, Mar 1, 2018 at 4:27 PM, Michal Hocko mhocko@kernel.org wrote:
On Thu 01-03-18 16:09:35, Daniel Vacek wrote:
From registers and stack I digged start_page points to ffffe31d01ed8000 (note that this is page ffffe31d01edffc0 aligned to pageblock) and I can see this in memory dump:
crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b7fe000 7b7ff000 7b800000 7ffff000 80000000 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffe31d01e00000 78000000 0 0 0 0 ffffe31d01ed7fc0 7b5ff000 0 0 0 0 ffffe31d01ed8000 7b600000 0 0 0 0 <<<< note
Are those ranges covered by the System RAM as well?
Sorry I forgot to answer this. If they were, the loop won't be skipping them, right? But it really does not matter here, kernel needs (some) page structures initialized anyways. And I do not feel comfortable with removing the VM_BUG_ON(). The initialization is what changed with commit b92df1de5d28, hence fixing this.
--nX
that nodeid and zonenr are encoded in top bits of page flags which are not initialized here, hence the crash :-( ffffe31d01edff80 7b7fe000 0 0 0 0 ffffe31d01edffc0 7b7ff000 0 0 1 1fffff00000000 ffffe31d01ee0000 7b800000 0 0 1 1fffff00000000 ffffe31d01ffffc0 7ffff000 0 0 1 1fffff00000000
It is still not clear why not to do the alignment in memblock_next_valid_pfn rahter than its caller. -- Michal Hocko SUSE Labs