Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

From	Michal Hocko <mhocko@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH v2 1/2] mm: Uncharge poisoned pages
Date	2017-05-09 11:20 +0200
Message-ID	<tF9tf-8dd-5@gated-at.bofh.it> (permalink)
References	(5 earlier) <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> <tEHdD-6Cr-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Mon 08-05-17 02:58:36, Naoya Horiguchi wrote:
> On Tue, May 02, 2017 at 08:55:07PM +0200, 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().
> 
> # sorry for late reply, I was on holidays last week...
> 
> Right, and the refcount taken for memory_failure is not freed after
> memory_failure() returns. unpoison_memory() does free the refcount.

OK, from the charge POV this would be safe because we clear page->memcg
so it wouldn't get uncharged more times.

> > > 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?
> 
> memory_failure() can be called for any types of page (including slab or
> any kernel/driver pages), and the reported problem seems happen only on
> in-use user pages, so uncharging in delete_from_lru_cache() as done below
> looks better to me.

Yeah, we do see problems only for LRU/page cache pages but my
understanding is that error_states (e.g. me_kernel for the kernel
memory) might change in the future and then we wouldn't catch the same
bug, no?

> > ---
> > 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>
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>

Thanks! I will wait a day or two for Johannes and repost the patch.
Andrew could you drop
http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-uncharge-poisoned-pages.patch
in the mean time, please?

-- 
Michal Hocko
SUSE Labs

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