Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1634899
| From | Laurent Dufour <ldufour@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 1/2] mm: Uncharge poisoned pages |
| Date | 2017-05-03 13:40 +0200 |
| Message-ID | <tD0Ns-4I5-5@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <tB8Fr-4jD-9@gated-at.bofh.it> <tBaed-5ps-7@gated-at.bofh.it> <tBerw-80m-17@gated-at.bofh.it> <tCHrt-7Ws-31@gated-at.bofh.it> <tCLbH-1Zs-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 02/05/2017 20:55, Michal Hocko wrote:
> On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
>> On 28/04/2017 15:48, Michal Hocko wrote:
> [...]
>>> This is getting quite hairy. What is the expected page count of the
>>> hwpoison page?
>
> OK, so from the quick check of the hwpoison code it seems that the ref
> count will be > 1 (from get_hwpoison_page).
>
>>> I guess we would need to update the VM_BUG_ON in the
>>> memcg uncharge code to ignore the page count of hwpoison pages if it can
>>> be arbitrary.
>>
>> Based on the experiment I did, page count == 2 when isolate_lru_page()
>> succeeds, even in the case of a poisoned page.
>
> that would make some sense to me. The page should have been already
> unmapped therefore but memory_failure increases the ref count and 1 is
> for isolate_lru_page().
>
>> In my case I think this
>> is because the page is still used by the process which is calling madvise().
>>
>> I'm wondering if I'm looking at the right place. May be the poisoned
>> page should remain attach to the memory_cgroup until no one is using it.
>> In that case this means that something should be done when the page is
>> off-lined... I've to dig further here.
>
> No, AFAIU the page will not drop the reference count down to 0 in most
> cases. Maybe there are some scenarios where this can happen but I would
> expect that the poisoned page will be mapped and in use most of the time
> and won't drop down 0. And then we should really uncharge it because it
> will pin the memcg and make it unfreeable which doesn't seem to be what
> we want. So does the following work reasonable? Andi, Johannes, what do
> you think? I cannot say I would be really comfortable touching hwpoison
> code as I really do not understand the workflow. Maybe we want to move
> this uncharge down to memory_failure() right before we report success?
> ---
> From 8bf0791bcf35996a859b6d33fb5494e5b53de49d Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Tue, 2 May 2017 20:32:24 +0200
> Subject: [PATCH] hwpoison, memcg: forcibly uncharge LRU pages
>
> Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In
> his particular case he has hit a bad_page("page still charged to cgroup")
> when onlining a hwpoison page. While this looks like something that shouldn't
> happen in the first place because onlining hwpages and returning them to
> the page allocator makes only little sense it shows a real problem.
>
> hwpoison pages do not get freed usually so we do not uncharge them (at
> least not since 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")).
> Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol: take a css
> reference for each charged page")) as well and so the mem_cgroup and the
> associated state will never go away. Fix this leak by forcibly
> uncharging a LRU hwpoisoned page in delete_from_lru_cache(). We also
> have to tweak uncharge_list because it cannot rely on zero ref count
> for these pages.
>
> Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")
> Reported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
FWIW:
Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> mm/memcontrol.c | 2 +-
> mm/memory-failure.c | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 16c556ac103d..4cf26059adb1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5527,7 +5527,7 @@ static void uncharge_list(struct list_head *page_list)
> next = page->lru.next;
>
> VM_BUG_ON_PAGE(PageLRU(page), page);
> - VM_BUG_ON_PAGE(page_count(page), page);
> + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
>
> if (!page->mem_cgroup)
> continue;
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 8a6bd3a9eb1e..4497d9619bb4 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -541,6 +541,13 @@ static int delete_from_lru_cache(struct page *p)
> */
> ClearPageActive(p);
> ClearPageUnevictable(p);
> +
> + /*
> + * Poisoned page might never drop its ref count to 0 so we have to
> + * uncharge it manually from its memcg.
> + */
> + mem_cgroup_uncharge(p);
> +
> /*
> * drop the page count elevated by isolate_lru_page()
> */
>
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2 0/2] BUG raised when onlining HWPoisoned page Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-25 16:30 +0200
[PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-25 16:30 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Balbir Singh <bsingharora@gmail.com> - 2017-04-26 04:20 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-04-26 05:30 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Balbir Singh <bsingharora@gmail.com> - 2017-04-28 05:00 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 08:40 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 09:00 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Michal Hocko <mhocko@kernel.org> - 2017-05-10 09:50 +0200
Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 09:00 +0200
[PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-25 16:30 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-04-26 02:00 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Balbir Singh <bsingharora@gmail.com> - 2017-04-26 04:00 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-04-26 05:20 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Balbir Singh <bsingharora@gmail.com> - 2017-04-26 05:50 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-04-26 06:50 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Balbir Singh <bsingharora@gmail.com> - 2017-04-26 11:10 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-28 11:40 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-04-27 16:40 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Andi Kleen <andi@firstfloor.org> - 2017-04-27 23:00 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 08:10 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 09:40 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-04-28 11:20 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-04-28 15:50 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-05-02 17:00 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-05-02 21:00 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-05-03 13:40 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Balbir Singh <bsingharora@gmail.com> - 2017-05-04 03:30 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-05-08 12:50 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Balbir Singh <bsingharora@gmail.com> - 2017-05-09 03:50 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-05-08 05:10 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Michal Hocko <mhocko@kernel.org> - 2017-05-09 11:20 +0200
Re: [PATCH v2 1/2] mm: Uncharge poisoned pages Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-05-10 01:10 +0200
csiph-web