Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   =?iso-2022-jp?B?SE9SSUdVQ0hJIE5BT1lBKBskQktZOH0hIUQ+TGkbKEIp?= 
        <naoya.horiguchi@nec.com>
To:     Oscar Salvador <osalvador@suse.de>
CC:     "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "aris@ruivo.org" <aris@ruivo.org>,
        "mhocko@kernel.org" <mhocko@kernel.org>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "cai@lca.pw" <cai@lca.pw>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH v4 1/7] mm,hwpoison: take free pages off the buddy
 freelists
Thread-Topic: [PATCH v4 1/7] mm,hwpoison: take free pages off the buddy
 freelists
Thread-Index: AQHWjMx3crVad5fTGEWr4+KBqX/ffal4q8WA
Date:   Fri, 25 Sep 2020 02:22:15 +0000
Message-ID: <20200925022214.GA31132@hori.linux.bs1.fc.nec.co.jp>
References: <20200917081049.27428-1-osalvador@suse.de>
 <20200917081049.27428-2-osalvador@suse.de>
In-Reply-To: <20200917081049.27428-2-osalvador@suse.de>
Accept-Language: ja-JP, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <E4A8C6559884064CBF814021959C21E0@jpnprd01.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a89d541-fde7-472f-6cd9-08d860f9d204
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 02:22:15.6175
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e67df547-9d0d-4f4d-9161-51c6ed1f7d11
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0oAEh7cduqO+vKSvVetXWopyVBhOkKdBFD5xJmc7iHvAHrrygd0Wn+mAYqyA6Ao7RW9NcryC/f1sRrX7wKWDYA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYBPR01MB5486
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Sep 17, 2020 at 10:10:43AM +0200, Oscar Salvador wrote:
> The crux of the matter is that historically we left poisoned pages in the
> buddy system because we have some checks in place when allocating a page
> that a gatekeeper for poisoned pages.  Unfortunately, we do have other
> users (e.g: compaction [1]) that scan buddy freelists and try to get a
> page from there without checking whether the page is HWPoison.
>=20
> As I stated already, I think it is fundamentally wrong to keep HWPoison
> pages within the buddy systems, checks in place or not.
>=20
> Let us fix this we same way we did for soft_offline [2], and take the pag=
e
> off the buddy freelist, so it is completely unreachable.
>=20
> Note that this is fairly simple to trigger, as we only need to poison fre=
e
> buddy pages (madvise MADV_HWPOISON) and then we need to run some sort of
> memory stress system.
>=20
> Just for a matter of reference, I put a dump_page in compaction_alloc to
> trigger for HWPoison patches:
>=20
> kernel: page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000=
000 index:0x1 pfn:0x1d5db
> kernel: flags: 0xfffffc0800000(hwpoison)
> kernel: raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 000000000=
0000000
> kernel: raw: 0000000000000001 0000000000000000 00000001ffffffff 000000000=
0000000
> kernel: page dumped because: compaction_alloc
>=20
> kernel: CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G            E     5.9.=
0-rc2-mm1-1-default+ #5
> kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1=
.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> kernel: Call Trace:
> kernel:  dump_stack+0x6d/0x8b
> kernel:  compaction_alloc+0xb2/0xc0
> kernel:  migrate_pages+0x2a6/0x12a0
> kernel:  ? isolate_freepages+0xc80/0xc80
> kernel:  ? __ClearPageMovable+0xb0/0xb0
> kernel:  compact_zone+0x5eb/0x11c0
> kernel:  ? finish_task_switch+0x74/0x300
> kernel:  ? lock_timer_base+0xa8/0x170
> kernel:  proactive_compact_node+0x89/0xf0
> kernel:  ? kcompactd+0x2d0/0x3a0
> kernel:  kcompactd+0x2d0/0x3a0
> kernel:  ? finish_wait+0x80/0x80
> kernel:  ? kcompactd_do_work+0x350/0x350
> kernel:  kthread+0x118/0x130
> kernel:  ? kthread_associate_blkcg+0xa0/0xa0
> kernel:  ret_from_fork+0x22/0x30
>=20
> After that, if e.g: someone faults in the page, that someone will get
> killed unexpectedly.
>=20
> While we are at it, I also changed the action result for such cases.
> I think that MF_DELAYED is a bit misleading, because in case we could
> contain the page and take it off the buddy, such a page is not to be used
> again unless it is unpoisoned, so we fixed the situation.
>=20
> So unless I am missing something, I strongly think that we should report
> MF_RECOVERED.
>=20
> [1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
> [2] https://patchwork.kernel.org/patch/11694847/
>=20
> Signed-off-by: Oscar Salvador <osalvador@suse.de>

Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>=