On Thu, Mar 1, 2018 at 4:27 PM, Michal Hocko <mhocko@xxxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
