linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
	Oscar Salvador <osalvador@suse.de>,
	Miaohe Lin <linmiaohe@huawei.com>
Subject: [PATCH 0/2] Reliable testing for hugetlb
Date: Thu, 14 Mar 2024 01:25:00 +0000	[thread overview]
Message-ID: <20240314012506.1600378-1-willy@infradead.org> (raw)

We need to handle pages allocated by hugetlbfs differently in a number of
places.  If we have a reference to the folio, there are many methods which
will work.  If we don't, most of our previous attempts can misidentify a
page which never belonged to hugetlb as belonging to hugetlb.  It's quite
hard to hit these kinds of races, and generally the results are relatively
benign, but I don't feel good about them existing.  Obviously since we
don't have a reference to the page, the answer can be stale ("it was part
of hugetlb when we asked, but now it isn't"), but that's very different
from "This page never belonged to hugetlb, but we said it did".

We've tried various things in the past.  My most recent approach was
to use a bit in the second page's flags, reusing the "active" flag.
This is very susceptible to this problem.  Before that, we used to
check that folio_dtor (previously compound_dtor) had a specific value.
This field was also stored in the second page, shared with the LRU.
It was less susceptible to this problem, which may be why nobody noticed
it since its introduction in 2009.

We have considered various approaches to make folio_test_hugetlb() more
reliable.  We could use a word in the second page, but that occupies
space that we probably have a better use for.  We could use a word in
the third page, but then we have to test that there is a third page so
we don't run off the end of memmap.  We considered using a special value
in nr_pages_mapped, but weren't convinced we could ensure that it would
be unique if the second page was reallocated to a different purpose.

Using PageType is completely reliable.  It will never return true for a
page if that page was never in a hugetlb allocation.  It doesn't occupy
any extra space, and we have plenty of bits left in PageType.  It's also
the most efficient definition of PageHuge() we've ever had, allowing it
to be a static inline function rather than an exported function.

Matthew Wilcox (Oracle) (2):
  mm: Turn folio_test_hugetlb into a PageType
  mm: Remove a call to compound_head() from is_page_hwpoison()

 include/linux/mm.h         |  3 ++
 include/linux/page-flags.h | 73 +++++++++++++++++++-------------------
 mm/hugetlb.c               | 22 ++----------
 3 files changed, 42 insertions(+), 56 deletions(-)

-- 
2.43.0



             reply	other threads:[~2024-03-14  1:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-14  1:25 Matthew Wilcox (Oracle) [this message]
2024-03-14  1:25 ` [PATCH 1/2] mm: Turn folio_test_hugetlb into a PageType Matthew Wilcox (Oracle)
2024-03-14 10:26   ` David Hildenbrand
2024-03-14 14:33     ` Matthew Wilcox
2024-03-15  6:19       ` Miaohe Lin
2024-03-15 12:32         ` Matthew Wilcox
2024-03-18  1:45           ` Miaohe Lin
2024-03-14  1:25 ` [PATCH 2/2] mm: Remove a call to compound_head() from is_page_hwpoison() Matthew Wilcox (Oracle)
2024-03-14 10:26   ` David Hildenbrand
2024-03-15  6:38   ` Miaohe Lin

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=20240314012506.1600378-1-willy@infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).