From: Michal Hocko <mhocko@kernel.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Linux-MM <linux-mm@kvack.org>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted
Date: Fri, 2 Dec 2016 11:03:19 +0100 [thread overview]
Message-ID: <20161202100318.GF6830@dhcp22.suse.cz> (raw)
In-Reply-To: <20161202094933.jxcgvtth2poqdm3n@techsingularity.net>
On Fri 02-12-16 09:49:33, Mel Gorman wrote:
> On Fri, Dec 02, 2016 at 09:12:17AM +0100, Michal Hocko wrote:
> > On Fri 02-12-16 00:22:43, Mel Gorman wrote:
> > > Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
> > > defer debugging checks of pages allocated from the PCP") will allow the
> > > per-cpu list counter to be out of sync with the per-cpu list contents
> > > if a struct page is corrupted. This patch keeps the accounting in sync.
> > >
> > > Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP")
> > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > > cc: stable@vger.kernel.org [4.7+]
> >
> > I am trying to think about what would happen if we did go out of sync
> > and cannot spot a problem. Vlastimil has mentioned something about
> > free_pcppages_bulk looping for ever but I cannot see it happening right
> > now.
>
> free_pcppages_bulk can infinite loop if the page count is positive and
> there are no pages. While I've only seen this during development, a
> corrupted count loops here
>
> do {
> batch_free++;
> if (++pindex == NR_PCP_LISTS)
> pindex = 0;
> list = &pcp->lists[pindex];
> } while (list_empty(list));
>
> It would only be seen in a situation where struct page corruption was
> detected so it's rare.
OK, I was apparently sleeping when responding. I focused on t he outer
loop and that should just converge. But it is true that this inner loop
can just runaway... Could you add that to the changelog please? This
definitely warrants stable backport.
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:[~2016-12-02 10:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 0:22 [PATCH 0/2] High-order per-cpu cache v5 Mel Gorman
2016-12-02 0:22 ` [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted Mel Gorman
2016-12-02 3:47 ` Hillf Danton
2016-12-02 6:19 ` Vlastimil Babka
2016-12-02 9:30 ` Hillf Danton
2016-12-02 10:04 ` Michal Hocko
2016-12-02 11:02 ` Mel Gorman
2016-12-02 8:12 ` Michal Hocko
2016-12-02 9:49 ` Mel Gorman
2016-12-02 10:03 ` Michal Hocko [this message]
2016-12-02 0:22 ` [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman
2016-12-02 6:03 ` Joonsoo Kim
2016-12-02 8:21 ` Michal Hocko
2016-12-05 3:10 ` Joonsoo Kim
2016-12-02 9:04 ` Mel Gorman
2016-12-05 3:06 ` Joonsoo Kim
2016-12-05 9:57 ` Mel Gorman
2016-12-06 2:43 ` Joonsoo Kim
2016-12-06 13:53 ` Mel Gorman
2016-12-02 8:25 ` Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2016-12-02 11:29 [PATCH 0/2] High-order per-cpu cache v6 Mel Gorman
2016-12-02 11:29 ` [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted Mel Gorman
2016-12-02 11:53 ` Vlastimil Babka
2016-12-02 13:15 ` Michal Hocko
2016-12-05 3:39 ` Hillf Danton
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=20161202100318.GF6830@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brouer@redhat.com \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--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;
as well as URLs for NNTP newsgroup(s).