All of lore.kernel.org
 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: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21  7:44 [PATCH v3] mm, hugetlb: fix resv_huge_pages underflow on UFFDIO_COPY Mina Almasry
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-22 21:32     ` Mina Almasry
2021-05-24 18:07 ` Mike Kravetz
2021-05-25  0:11   ` Mina Almasry
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-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-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  3:19           ` Muchun Song
2021-05-26 17:17           ` Mike Kravetz
2021-05-26 23:19             ` Mina Almasry
2021-05-26 23:19               ` Mina Almasry
2021-05-27  2:48               ` 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 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.