All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Muchun Song <songmuchun@bytedance.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [External] Re: [PATCH] mm: hugetlb: fix a race between memory-failure/soft_offline and gather_surplus_pages
Date: Wed, 21 Apr 2021 10:43:26 +0200	[thread overview]
Message-ID: <YH/lrlmkEb5b8LCo@dhcp22.suse.cz> (raw)
In-Reply-To: <20210421082103.GE22456@linux>

On Wed 21-04-21 10:21:03, Oscar Salvador wrote:
> On Wed, Apr 21, 2021 at 04:15:00PM +0800, Muchun Song wrote:
> > > The hwpoison side of this looks really suspicious to me. It shouldn't
> > > really touch the reference count of hugetlb pages without being very
> > > careful (and having hugetlb_lock held). What would happen if the
> > > reference count was increased after the page has been enqueed into the
> > > pool? This can just blow up later.
> > 
> > If the page has been enqueued into the pool, then the page can be
> > allocated to other users. The page reference count will be reset to
> > 1 in the dequeue_huge_page_node_exact(). Then memory-failure
> > will free the page because of put_page(). This is wrong. Because
> > there is another user.
> 
> Note that dequeue_huge_page_node_exact() will not hand over any pages
> which are poisoned, so in this case it will not be allocated.

I have to say I have missed the HWPoison check so the this particular
scenario is not possible indeed.

> But it is true that we might need hugetlb lock, this needs some more
> thought.

yes, nobody should be touching to the reference count of hugetlb pool
pages out of the hugetlb proper.

> I will have a look. 

Thanks!
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2021-04-21  8:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  6:02 [PATCH] mm: hugetlb: fix a race between memory-failure/soft_offline and gather_surplus_pages Muchun Song
2021-04-21  8:03 ` Michal Hocko
2021-04-21  8:15   ` [External] " Muchun Song
2021-04-21  8:15     ` Muchun Song
2021-04-21  8:21     ` Oscar Salvador
2021-04-21  8:41       ` Muchun Song
2021-04-21  8:41         ` Muchun Song
2021-04-21  8:49         ` Oscar Salvador
2021-04-21  8:58           ` Muchun Song
2021-04-21  8:58             ` Muchun Song
2021-04-21  8:43       ` Michal Hocko [this message]
2021-04-21  8:25     ` Michal Hocko
2021-04-21  8:33   ` HORIGUCHI NAOYA(堀口　直也)
2021-04-21  9:02     ` [External] " Muchun Song
2021-04-21  9:02       ` Muchun Song
2021-04-21 18:03     ` Mike Kravetz
2021-04-22  8:27       ` HORIGUCHI NAOYA(堀口　直也)
2021-04-23  8:01         ` HORIGUCHI NAOYA(堀口　直也)
2021-04-28  7:46           ` [PATCH] mm,hwpoison: fix race with compound page allocation Naoya Horiguchi
2021-04-28  8:23             ` Oscar Salvador
2021-04-28  9:18               ` HORIGUCHI NAOYA(堀口　直也)
2021-05-06  1:31                 ` [PATCH v2] " Naoya Horiguchi
2021-05-06  8:51                   ` Oscar Salvador
2021-05-07  4:17                     ` HORIGUCHI NAOYA(堀口　直也)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YH/lrlmkEb5b8LCo@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=osalvador@suse.de \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.