Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751479AbbHQEdq (ORCPT <rfc822;w@1wt.eu>);
	Mon, 17 Aug 2015 00:33:46 -0400
Received: from TYO201.gate.nec.co.jp ([210.143.35.51]:48183 "EHLO
	tyo201.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751310AbbHQEdo convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 17 Aug 2015 00:33:44 -0400
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Wanpeng Li <wanpeng.li@hotmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Naoya Horiguchi <nao.horiguchi@gmail.com>,
        Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH] mm/hwpoison: fix race between soft_offline_page and
 unpoison_memory
Thread-Topic: [PATCH] mm/hwpoison: fix race between soft_offline_page and
 unpoison_memory
Thread-Index: AQHQ2KWtXadvekPJDkSy7TeSGMowdw==
Date: Mon, 17 Aug 2015 04:32:08 +0000
Message-ID: <1439785924-27885-1-git-send-email-n-horiguchi@ah.jp.nec.com>
References: <BLU436-SMTP2235CDFEDA4DEB534BF8C85807C0@phx.gbl>
In-Reply-To: <BLU436-SMTP2235CDFEDA4DEB534BF8C85807C0@phx.gbl>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.128.101.1]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3118
Lines: 61

On Fri, Aug 14, 2015 at 05:01:34PM +0800, Wanpeng Li wrote:
> On 8/14/15 4:38 PM, Naoya Horiguchi wrote:
> > On Fri, Aug 14, 2015 at 03:59:21PM +0800, Wanpeng Li wrote:
> >> On 8/14/15 3:54 PM, Wanpeng Li wrote:
> >>> [...]
> >>>> OK, then I rethink of handling the race in unpoison_memory().
> >>>>
> >>>> Currently properly contained/hwpoisoned pages should have page refcount 1
> >>>> (when the memory error hits LRU pages or hugetlb pages) or refcount 0
> >>>> (when the memory error hits the buddy page.) And current unpoison_memory()
> >>>> implicitly assumes this because otherwise the unpoisoned page has no place
> >>>> to go and it's just leaked.
> >>>> So to avoid the kernel panic, adding prechecks of refcount and mapcount
> >>>> to limit the page to unpoison for only unpoisonable pages looks OK to me.
> >>>> The page under soft offlining always has refcount >=2 and/or mapcount > 0,
> >>>> so such pages should be filtered out.
> >>>>
> >>>> Here's a patch. In my testing (run soft offline stress testing then repeat
> >>>> unpoisoning in background,) the reported (or similar) bug doesn't happen.
> >>>> Can I have your comments?
> >>> As page_action() prints out page maybe still referenced by some users,
> >>> however, PageHWPoison has already set. So you will leak many poison pages.
> >>>
> >> Anyway, the bug is still there.
> >>
> >> [  944.387559] BUG: Bad page state in process expr  pfn:591e3
> >> [  944.393053] page:ffffea00016478c0 count:-1 mapcount:0 mapping:
> >> (null) index:0x2
> >> [  944.401147] flags: 0x1fffff80000000()
> >> [  944.404819] page dumped because: nonzero _count
> > Hmm, no luck :(
> >
> > To investigate more, I'd like to test the exactly same kernel as yours, so
> > could you share the kernel info (.config and base kernel and what patches
> > you applied)? or pushing your tree somewhere like github?
> > # if you like, sending to me privately is fine.
> >
> > I think that I tested v4.2-rc6 + <your recent 7 hwpoison patches> +
> > "mm/hwpoison: fix race between soft_offline_page and unpoison_memory",
> > but I experienced some conflict in applying your patches for some reason,
> > so it might happen that we are testing on different kernels.
> 
> I don't have special config and tree, the latest mmotm has already
> merged my recent 8 hwpoison patches, you can test based on it.

OK, so I wrote the next version against mmotm-2015-08-13-15-29 (replied to
this email.) It moves PageSetHWPoison part into migration code, which should
close up the reported race window and minimize the another revived race window
of reusing offlined pages, so I feel that it's a good compromise between two
races.

My testing shows no kernel panic with these patches (same testing easily caused
panics for bare mmotm-2015-08-13-15-29,) so they should work. But I'm appreciated
if you help double checking.

Thanks,
Naoya Horiguchi--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/