linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mina Almasry <almasrymina@google.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>,
	Peter Xu <peterx@redhat.com>,
	linux-mm@kvack.org, Mike Kravetz <mike.kravetz@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm, hugetlb: fix resv_huge_pages underflow on UFFDIO_COPY
Date: Sat, 22 May 2021 14:19:46 -0700	[thread overview]
Message-ID: <20210522141946.f8a62010350a76302b9508fb@linux-foundation.org> (raw)
In-Reply-To: <20210521074433.931380-1-almasrymina@google.com>

On Fri, 21 May 2021 00:44:33 -0700 Mina Almasry <almasrymina@google.com> wrote:

> The userfaultfd hugetlb tests detect a resv_huge_pages underflow. This
> happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on
> an index for which we already have a page in the cache. When this
> happens, we allocate a second page, double consuming the reservation,
> and then fail to insert the page into the cache and return -EEXIST.
> 
> To fix this, we first if there exists a page in the cache which already

                       ^ check

> consumed the reservation, and return -EEXIST immediately if so.
> 
> Secondly, if we fail to copy the page contents while holding the
> hugetlb_fault_mutex, we will drop the mutex and return to the caller
> after allocating a page that consumed a reservation. In this case there
> may be a fault that double consumes the reservation. To handle this, we
> free the allocated page, fix the reservations, and allocate a temporary
> hugetlb page and return that to the caller. When the caller does the
> copy outside of the lock, we again check the cache, and allocate a page
> consuming the reservation, and copy over the contents.
> 
> Test:
> Hacked the code locally such that resv_huge_pages underflows produce
> a warning and the copy_huge_page_from_user() always fails, then:
> 
> ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10
> 	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
> ./tools/testing/selftests/vm/userfaultfd hugetlb 10
> 	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
> 
> Both tests succeed and produce no warnings. After the test runs
> number of free/resv hugepages is correct.
>
> ...
>
>  include/linux/hugetlb.h |   4 ++
>  mm/hugetlb.c            | 103 ++++++++++++++++++++++++++++++++++++----
>  mm/migrate.c            |  39 +++------------
>  3 files changed, 103 insertions(+), 43 deletions(-)

I'm assuming we want this in -stable?

Are we able to identify a Fixes: for this?

It's a large change.  Can we come up with some smaller and easier to
review and integrate version which we can feed into 5.13 and -stable
and do the fancier version for 5.14?

If you don't think -stable needs this then this version will be OK as-is.


  reply	other threads:[~2021-05-22 21:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21  7:44 Mina Almasry
2021-05-22 21:19 ` Andrew Morton [this message]
2021-05-22 21:32   ` Mina Almasry
2021-05-24 18:07 ` Mike Kravetz
2021-05-25  0:11   ` Mina Almasry
2021-05-25  0:45     ` Mike Kravetz
2021-05-25 23:31       ` [PATCH 0/2] Track reserve map changes to restore on error Mike Kravetz
2021-05-25 23:31         ` [PATCH 1/2] hugetlb: rename HPageRestoreReserve flag to HPageRestoreRsvCnt Mike Kravetz
2021-05-27  2:49           ` Mina Almasry
2021-05-25 23:31         ` [PATCH 2/2] hugetlb: add new hugetlb specific flag HPG_restore_rsv_map Mike Kravetz
2021-05-27  2:58           ` Mina Almasry
2021-05-26  3:19         ` [External] [PATCH 0/2] Track reserve map changes to restore on error Muchun Song
2021-05-26 17:17           ` Mike Kravetz
2021-05-26 23:19             ` Mina Almasry
2021-05-27  2:48               ` Mina Almasry
2021-05-27 16:08                 ` Mike Kravetz

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=20210522141946.f8a62010350a76302b9508fb@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=axelrasmussen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox