[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec66e12d8140ba117a0e98c37f6557bd@suse.de>
Date: Thu, 06 Dec 2018 09:40:23 +0100
From: osalvador@...e.de
To: Michal Hocko <mhocko@...nel.org>
Cc: Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Oscar Salvador <OSalvador@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...il.com>,
Pavel Tatashin <pasha.tatashin@...een.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>,
Stable tree <stable@...r.kernel.org>, owner-linux-mm@...ck.org
Subject: Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to
be offlined
>> This commit adds shake_page() for mlocked pages to make sure that the
>> target
>> page is flushed out from LRU cache. Without this shake_page(),
>> subsequent
>> delete_from_lru_cache() (from me_pagecache_clean()) fails to isolate
>> it and
>> the page will finally return back to LRU list. So this scenario leads
>> to
>> "hwpoisoned by still linked to LRU list" page.
>
> OK, I see. So does that mean that the LRU handling is no longer needed
> and there is a guanratee that all kernels with the above commit cannot
> ever get an LRU page?
For the sake of completeness:
I made a quick test reverting 286c469a988 on upstream kernel.
As expected, the poisoned page is in LRU when it hits do_migrate_range,
and so, the migration path is taken and I see the exact failure I saw
on. 4.4
Oscar Salvador
---
Suse L3
Powered by blists - more mailing lists