All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Li Wang <liwang@redhat.com>, Minchan Kim <minchan@kernel.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: v5.1-rc5 s390x WARNING
Date: Thu, 18 Apr 2019 14:54:52 +0100	[thread overview]
Message-ID: <20190418135452.GF18914@techsingularity.net> (raw)
In-Reply-To: <73fbe83d-97d8-c05f-38fa-5e1a0eec3c10@suse.cz>

On Wed, Apr 17, 2019 at 10:54:38AM +0200, Vlastimil Babka wrote:
> On 4/17/19 10:35 AM, Li Wang wrote:
> > Hi there,
> > 
> > I catched this warning on v5.1-rc5(s390x). It was trggiered in fork & malloc & memset stress test, but the reproduced rate is very low. I'm working on find a stable reproducer for it. 
> > 
> > Anyone can have a look first?
> > 
> > [ 1422.124060] WARNING: CPU: 0 PID: 9783 at mm/page_alloc.c:3777 __alloc_pages_irect_compact+0x182/0x190
> 
> This means compaction was either skipped or deferred, yet it captured a
> page. We have some registers with value 1 and 2, which is
> COMPACT_SKIPPED and COMPACT_DEFERRED, so it could be one of those.
> Probably COMPACT_SKIPPED. I think a race is possible:
> 
> - compact_zone_order() sets up current->capture_control
> - compact_zone() calls compaction_suitable() which returns
> COMPACT_SKIPPED, so it also returns
> - interrupt comes and its processing happens to free a page that forms
> high-order page, since 'current' isn't changed during interrupt (IIRC?)
> the capture_control is still active and the page is captured
> - compact_zone_order() does *capture = capc.page
> 
> What do you think, Mel, does it look plausible?

It's plausible, just extremely unlikely. I think the most likely result
was that a page filled the per-cpu lists and a bunch of pages got freed
in a batch from interrupt context.

> Not sure whether we want
> to try avoiding this scenario, or just remove the warning and be
> grateful for the successful capture :)
> 

Avoiding the scenario is pointless because it's not wrong. The check was
initially meant to catch serious programming errors such as using a
stale page pointer so I think the right patch is below. Li Wang, how
reproducible is this and would you be willing to test it?

---8<---
mm, page_alloc: Always use a captured page regardless of compaction result

During the development of commit 5e1f0f098b46 ("mm, compaction: capture
a page under direct compaction"), a paranoid check was added to ensure
that if a captured page was available after compaction that it was
consistent with the final state of compaction. The intent was to catch
serious programming bugs such as using a stale page pointer and causing
corruption problems.

However, it is possible to get a captured page even if compaction was
unsuccessful if an interrupt triggered and happened to free pages in
interrupt context that got merged into a suitable high-order page. It's
highly unlikely but Li Wang did report the following warning on s390

[ 1422.124060] WARNING: CPU: 0 PID: 9783 at mm/page_alloc.c:3777 __alloc_pages_irect_compact+0x182/0x190
[ 1422.124065] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver
 nfs lockd grace fscache sunrpc pkey ghash_s390 prng xts aes_s390 des_s390
 des_generic sha512_s390 zcrypt_cex4 zcrypt vmur binfmt_misc ip_tables xfs
 libcrc32c dasd_fba_mod qeth_l2 dasd_eckd_mod dasd_mod qeth qdio lcs ctcm
 ccwgroup fsm dm_mirror dm_region_hash dm_log dm_mod
[ 1422.124086] CPU: 0 PID: 9783 Comm: copy.sh Kdump: loaded Not tainted 5.1.0-rc 5 #1

This patch simply removes the check entirely instead of trying to be
clever about pages freed from interrupt context. If a serious programming
error was introduced, it is highly likely to be caught by prep_new_page()
instead.

Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction")
Reported-by: Li Wang <liwang@redhat.com>
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
---
 mm/page_alloc.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d96ca5bc555b..cfaba3889fa2 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3773,11 +3773,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 	memalloc_noreclaim_restore(noreclaim_flag);
 	psi_memstall_leave(&pflags);
 
-	if (*compact_result <= COMPACT_INACTIVE) {
-		WARN_ON_ONCE(page);
-		return NULL;
-	}
-
 	/*
 	 * At least in one zone compaction wasn't deferred or skipped, so let's
 	 * count a compaction stall


  reply	other threads:[~2019-04-18 13:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17  8:35 v5.1-rc5 s390x WARNING Li Wang
2019-04-17  8:54 ` Vlastimil Babka
2019-04-18 13:54   ` Mel Gorman [this message]
2019-04-18 14:37     ` Matthew Wilcox
2019-04-18 15:25       ` Mel Gorman
2019-04-19 12:53         ` Vlastimil Babka
2019-04-19  8:41     ` Li Wang
2019-04-19  8:52       ` Mel Gorman
2019-04-19 12:51     ` Vlastimil Babka

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=20190418135452.GF18914@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=linux-mm@kvack.org \
    --cc=liwang@redhat.com \
    --cc=minchan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.