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 v4] mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY
Date: Mon, 31 May 2021 16:25:27 -0700 [thread overview]
Message-ID: <20210531162527.caeae9545ea2843c5f62bc9c@linux-foundation.org> (raw)
In-Reply-To: <20210528005029.88088-1-almasrymina@google.com>
On Thu, 27 May 2021 17:50:29 -0700 Mina Almasry <almasrymina@google.com> wrote:
> On UFFDIO_COPY, 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.
Many conflicts here with material that is queued for 5.14-rc1.
How serious is this problem? Is a -stable backport warranted?
If we decide to get this into 5.13 (and perhaps -stable) then I can
take a look at reworking all the 5.14 material on top. If not very
serious then we could rework this on top of the already queued
material.
next prev parent reply other threads:[~2021-05-31 23:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 0:50 [PATCH v4] mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY Mina Almasry
2021-05-31 23:25 ` Andrew Morton [this message]
2021-06-01 0:11 ` Mina Almasry
2021-06-01 0:36 ` Andrew Morton
2021-06-01 2:48 ` Mina Almasry
2021-06-01 17:09 ` Mike Kravetz
2021-06-01 18:04 ` Mina Almasry
2021-06-01 18:05 ` Mina Almasry
2021-06-04 21:41 ` Mike Kravetz
2021-06-05 1:06 ` [PATCH] mm, hugetlb: fix allocation error check and copy func name Mina Almasry
2021-06-05 12:49 ` [External] " Muchun Song
2021-06-07 20:32 ` 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=20210531162527.caeae9545ea2843c5f62bc9c@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;
as well as URLs for NNTP newsgroup(s).