All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Muchun Song <songmuchun@bytedance.com>
Cc: "Mike Kravetz" <mike.kravetz@oracle.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	"Peter Zijlstra" <peterz@infradead.org>,
	viro@zeniv.linux.org.uk,
	"Andrew Morton" <akpm@linux-foundation.org>,
	paulmck@kernel.org, mchehab+huawei@kernel.org,
	pawan.kumar.gupta@linux.intel.com,
	"Randy Dunlap" <rdunlap@infradead.org>,
	oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de,
	"Mina Almasry" <almasrymina@google.com>,
	"David Rientjes" <rientjes@google.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Michal Hocko" <mhocko@suse.com>,
	"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
	"David Hildenbrand" <david@redhat.com>,
	"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
	"Joao Martins" <joao.m.martins@oracle.com>,
	"Xiongchun duan" <duanxiongchun@bytedance.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Linux Memory Management List" <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page
Date: Tue, 23 Feb 2021 16:41:28 +0100	[thread overview]
Message-ID: <20210223154128.GA21082@localhost.localdomain> (raw)
In-Reply-To: <20210223104957.GA3844@linux>

On Tue, Feb 23, 2021 at 11:50:05AM +0100, Oscar Salvador wrote:
> > CPU0:                           CPU1:
> >                                 set_compound_page_dtor(HUGETLB_PAGE_DTOR);
> > memory_failure_hugetlb
> >   get_hwpoison_page
> >     __get_hwpoison_page
> >       get_page_unless_zero
> >                                 put_page_testzero()
> > 
> > Maybe this can happen. But it is a very corner case. If we want to
> > deal with this. We can put_page_testzero() first and then
> > set_compound_page_dtor(HUGETLB_PAGE_DTOR).
> 
> I have to check further, but it looks like this could actually happen.
> Handling this with VM_BUG_ON is wrong, because memory_failure/soft_offline are
> entitled to increase the refcount of the page.
> 
> AFAICS,
> 
>  CPU0:                                    CPU1:
>                                           set_compound_page_dtor(HUGETLB_PAGE_DTOR);
>  memory_failure_hugetlb
>    get_hwpoison_page
>      __get_hwpoison_page
>        get_page_unless_zero
>                                           put_page_testzero()
>         identify_page_state
>          me_huge_page
> 
> I think we can reach me_huge_page with either refcount = 1 or refcount =2,
> depending whether put_page_testzero has been issued.
> 
> For now, I would not re-enqueue the page if put_page_testzero == false.
> I have to see how this can be handled gracefully.

I took a brief look.
It is not really your patch fault. Hugetlb <-> memory-failure synchronization is
a bit odd, it definitely needs improvment.

The thing is, we can have different scenarios here.
E.g: by the time we return from put_page_testzero, we might have refcount ==
0 and PageHWPoison, or refcount == 1 PageHWPoison.

The former will let a user get a page from the pool and get a sigbus
when it faults in the page, and the latter will be even more odd as we
will have a self-refcounted page in the free pool (and hwpoisoned).

As I said, it is not this patchset fault. I just made me realize this
problem.

I have to think some more about this.

-- 
Oscar Salvador
SUSE L3

  reply	other threads:[~2021-02-23 15:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 10:49 [PATCH v16 0/9] Free some vmemmap pages of HugeTLB page Muchun Song
2021-02-19 10:49 ` [PATCH v16 1/9] mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c Muchun Song
2021-02-19 10:49 ` [PATCH v16 2/9] mm: hugetlb: introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2021-02-19 10:49 ` [PATCH v16 3/9] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page Muchun Song
2021-02-19 10:49 ` [PATCH v16 4/9] mm: hugetlb: alloc " Muchun Song
2021-02-19 14:12   ` Michal Hocko
2021-02-20  4:20     ` [External] " Muchun Song
2021-02-22  9:25       ` Michal Hocko
2021-02-22 10:31         ` Muchun Song
2021-02-22 10:50           ` Oscar Salvador
2021-02-23  0:00   ` Mike Kravetz
2021-02-23  5:35     ` [External] " Muchun Song
2021-02-23  9:27     ` Oscar Salvador
2021-02-23 10:27       ` [External] " Muchun Song
2021-02-23 10:50         ` Oscar Salvador
2021-02-23 15:41           ` Oscar Salvador [this message]
2021-02-23 22:31             ` Oscar Salvador
2021-02-24  3:47               ` Muchun Song
2021-02-24  8:31                 ` Oscar Salvador
2021-02-19 10:49 ` [PATCH v16 5/9] mm: hugetlb: set the PageHWPoison to the raw error page Muchun Song
2021-02-19 10:49 ` [PATCH v16 6/9] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Muchun Song
2021-02-19 10:49 ` [PATCH v16 7/9] mm: hugetlb: introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2021-02-19 10:49 ` [PATCH v16 8/9] mm: hugetlb: gather discrete indexes of tail page Muchun Song
2021-02-19 10:49 ` [PATCH v16 9/9] mm: hugetlb: optimize the code with the help of the compiler Muchun Song

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=20210223154128.GA21082@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=hpa@zytor.com \
    --cc=joao.m.martins@oracle.com \
    --cc=jroedel@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=oneukum@suse.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=songmuchun@bytedance.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /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.