On Thu 01-03-18 17:20:04, Daniel Vacek wrote: > 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: > > [...] > >> $ grep 7b7ff000 /proc/iomem > >> 7b7ff000-7b7fffff : System RAM > > [...] > >> After commit b92df1de5d28 machine eventually crashes with: > >> > >> BUG at mm/page_alloc.c:1913 > >> > >> > VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); > > > > This is an important information that should be in the changelog. > > And that's exactly what my seven very first words tried to express in > human readable form instead of mechanically pasting the source code. I > guess that's a matter of preference. Though I see grepping later can > be an issue here. Do not get me wrong I do not want to nag just for fun of it. The changelog should be really clear about the problem. What might be clear to you based on the debugging might not be so clear to others. And the struct page initialization code is far from trivial especially when we have different alignment requirements by the memory model and the page allocator. Therefore being as clear as possible is really valuable. So I would really love to see the changelog to contain. - What is going on - VM_BUG_ON in move_freepages along with the crash report - memory ranges exported by BIOS/FW - explain why is the pageblock alignment the proper one. How does the range look from the memory section POV (with SPARSEMEM). - What about those unaligned pages which are not backed by any memory? Are they reserved so that they will never get used? And just to be clear. I am not saying your patch is wrong. It just raises more questions than answers and I suspect it just papers over some more fundamental problem. I might be clearly wrong and I cannot deserve this more time for the next week because I will be offline but I would _really_ appreciate if this all got explained. Thanks! -- Michal Hocko SUSE Labs