From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
tony.luck@intel.com, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>,
dave.hansen@linux.intel.com
Subject: Re: [PATCH] hwpoison: Fix race with changing page during offlining
Date: Thu, 26 Jun 2014 15:50:36 -0400 [thread overview]
Message-ID: <20140626195036.GA5311@nhori.redhat.com> (raw)
In-Reply-To: <1403806972-14267-1-git-send-email-andi@firstfloor.org>
Thank you for testing/reporting.
On Thu, Jun 26, 2014 at 11:22:52AM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> While running the mcelog test suite on 3.14 I hit the following VM_BUG_ON:
>
> soft_offline: 0x56d4: unknown non LRU page type 3ffff800008000
This line comes from error path in get_any_page(), I guess this function was
called for a thp (due to the race between thp collapse and soft offlining.)
But in this case soft offlining is not tried, so there's no harm from this.
> page:ffffea000015b400 count:3 mapcount:2097169 mapping: (null) index:0xffff8800056d7000
> page flags: 0x3ffff800004081(locked|slab|head)
> ------------[ cut here ]------------
> kernel BUG at mm/rmap.c:1495!
This seems to be caused by calling try_to_unmap() for a slab page, which
was called from hwpoison_user_mappings().
>
> I think what happened is that a LRU page turned into a slab page in parallel
> with offlining. memory_failure initially tests for this case, but doesn't
> retest later after the page has been locked.
>
> This patch fixes this race. It also check for the case that the page
> changed compound pages.
>
> Unfortunately since it's a race I wasn't able to reproduce later,
> so the specific case is not tested.
>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: dave.hansen@linux.intel.com
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> mm/memory-failure.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 90002ea..e277726a 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1143,6 +1143,22 @@ int memory_failure(unsigned long pfn, int trapno, int flags)
> lock_page(hpage);
>
> /*
> + * The page could have turned into a non LRU page or
> + * changed compound pages during the locking.
> + * If this happens just bail out.
> + */
> + if (compound_head(p) != hpage) {
> + action_result(pfn, "different compound page after locking", IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
This is a useful check.
> + if (!PageLRU(hpage)) {
> + action_result(pfn, "non LRU after locking", IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
I think this makes sense in v3.14, but maybe redundant if the patch "hwpoison:
fix the handling path of the victimized page frame that belong to non-LRU"
from Chen Yucong is merged into mainline (now it's in linux-mmotm).
And I think that the problem you report is caused by another part of hwpoison
code, because we have PageSlab check at the beginning of hwpoison_user_mappings(),
so if LRU page truned into slab page just before locking the page, we never
reach try_to_unmap().
I think this was caused by the code around lock migration after thp split
in hwpoison_user_mappings(), which was introduced in commit 54b9dd14d09f
("mm/memory-failure.c: shift page lock from head page to tail page after thp split").
I guess the tail page (raw error page) was freed and turned into Slab page
just after thp split and before locking the error page.
So possible solution is to do page status check again after thp split.
Thanks,
Naoya Horiguchi
--
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:[~2014-06-26 19:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 18:22 [PATCH] hwpoison: Fix race with changing page during offlining Andi Kleen
2014-06-26 19:50 ` Naoya Horiguchi [this message]
2014-06-26 19:56 ` Andrew Morton
2014-07-01 17:57 ` Andi Kleen
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=20140626195036.GA5311@nhori.redhat.com \
--to=n-horiguchi@ah.jp.nec.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tony.luck@intel.com \
/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).