From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: soldier.cyc81@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Wu Fengguang <fengguang.wu@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/memory-failure.c: fix memory leak by race between poison and unpoison
Date: Thu, 15 May 2014 10:13:59 -0400 [thread overview]
Message-ID: <5374cbc0.43b8b40a.4221.331eSMTPIN_ADDED_BROKEN@mx.google.com> (raw)
In-Reply-To: <5374b1d1.86300f0a.4a16.65ffSMTPIN_ADDED_BROKEN@mx.google.com>
On Thu, May 15, 2014 at 08:23:10AM -0400, Naoya Horiguchi wrote:
> On Thu, May 15, 2014 at 11:34:26AM +0800, cyc wrote:
> > 在 2014-05-14三的 11:21 -0400,Naoya Horiguchi写道:
> > > When a memory error happens on an in-use page or (free and in-use) hugepage,
> > > the victim page is isolated with its refcount set to one. When you try to
> > > unpoison it later, unpoison_memory() calls put_page() for it twice in order to
> > > bring the page back to free page pool (buddy or free hugepage list.)
> > > However, if another memory error occurs on the page which we are unpoisoning,
> > > memory_failure() returns without releasing the refcount which was incremented
> > > in the same call at first, which results in memory leak and unconsistent
> > > num_poisoned_pages statistics. This patch fixes it.
> >
> > We assume that a new memory error occurs on the hugepage which we are
> > unpoisoning.
> >
> > A unpoisoned B poisoned C
> > hugepage: |---------------+++++++++++++++++|
> >
> > There are two cases, so shown.
> > 1. the victim page belongs to A-B, the memory_failure will be blocked
> > by lock_page() until unlock_page() invoked by unpoison_memory().
>
> No. memory_failure() set PageHWPoison at first before taking page lock.
> This is a design choice based on the idea that we need detect errors ASAP.
I might have not caught you, sorry. With this patch, we can properly cancel
poisoning operation when it races with unpoisoning, so no effect as you said
for both case.
Thanks,
Naoya
> What happens in this race is like below:
>
> CPU 0 (poison) CPU 1 (unpoison)
> lock_page
> TestSetPageHWPoison
> TestClearPageHWPoison
> lock_page (wait)
> unlock_page
> check PageHWPoison
> printk("just unpoisoned")
>
> > 2. the victim page belongs to B-C, the memory_failure() will return
> > very soon at the beginning of this function.
>
> Right.
>
> 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>
>
--
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>
prev parent reply other threads:[~2014-05-15 14:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 15:21 Naoya Horiguchi
2014-05-14 22:10 ` Andrew Morton
2014-05-14 23:49 ` Naoya Horiguchi
2014-05-15 3:34 ` cyc
2014-05-15 12:23 ` Naoya Horiguchi
2014-05-15 14:13 ` Naoya Horiguchi [this message]
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=5374cbc0.43b8b40a.4221.331eSMTPIN_ADDED_BROKEN@mx.google.com \
--to=n-horiguchi@ah.jp.nec.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=soldier.cyc81@gmail.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