From: Michal Hocko <mhocko@kernel.org>
To: Daniel Vacek <neelx@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
Pavel Tatashin <pasha.tatashin@oracle.com>,
Paul Burton <paul.burton@imgtec.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: fix memmap_init_zone pageblock alignment
Date: Fri, 2 Mar 2018 14:01:20 +0100 [thread overview]
Message-ID: <20180302130052.GN15057@dhcp22.suse.cz> (raw)
In-Reply-To: <CACjP9X8hFDhkKUHRu2K5WgEp9YFHh2=vMSyM6KkZ5UZtxs7k-w@mail.gmail.com>
On Thu 01-03-18 17:20:04, Daniel Vacek wrote:
> 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:
> > [...]
> >> $ 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-03-02 13:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 12:47 Daniel Vacek
2018-03-01 13:10 ` Michal Hocko
2018-03-01 15:09 ` Daniel Vacek
2018-03-01 15:27 ` Michal Hocko
2018-03-01 16:20 ` Daniel Vacek
2018-03-01 23:21 ` Andrew Morton
2018-03-02 10:54 ` Daniel Vacek
2018-03-02 13:01 ` Michal Hocko [this message]
2018-03-02 15:27 ` Daniel Vacek
2018-03-01 17:24 ` Daniel Vacek
2018-03-02 11:01 ` [PATCH v2] " Daniel Vacek
2018-03-03 0:12 ` [PATCH v3 0/2] mm/page_alloc: fix kernel BUG at mm/page_alloc.c:1913! crash in move_freepages() Daniel Vacek
2018-03-03 0:12 ` [PATCH v3 1/2] mm/memblock: hardcode the end_pfn being -1 Daniel Vacek
2018-03-03 0:12 ` [PATCH v3 2/2] mm/page_alloc: fix memmap_init_zone pageblock alignment Daniel Vacek
2018-03-03 0:40 ` Andrew Morton
2018-03-03 1:08 ` Daniel Vacek
2018-03-12 12:26 ` Sudeep Holla
2018-03-12 14:49 ` Naresh Kamboju
2018-03-12 16:51 ` Daniel Vacek
2018-03-12 17:11 ` Sudeep Holla
2018-03-13 6:34 ` Naresh Kamboju
2018-03-13 22:47 ` Daniel Vacek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180302130052.GN15057@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=neelx@redhat.com \
--cc=pasha.tatashin@oracle.com \
--cc=paul.burton@imgtec.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox