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 <linux-mm@kvack.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	open list <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 17:36:52 -0700	[thread overview]
Message-ID: <20210531173652.c21404a16a8f8542ce40afa8@linux-foundation.org> (raw)
In-Reply-To: <CAHS8izMCb4Ws46X3xXGcmrvV6J36qsAPTVCA_gdcH65FU0OeUg@mail.gmail.com>

On Mon, 31 May 2021 17:11:52 -0700 Mina Almasry <almasrymina@google.com> wrote:

> On Mon, May 31, 2021 at 4:25 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > 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?
> >
> 
> I've sent 2 similar patches to the list:
> 
> 1. "[PATCH v4] mm, hugetlb: Fix simple resv_huge_pages underflow on UFFDIO_COPY"
> 
> This one is sent to -stable and linux-mm and is a fairly simple fix.
> 
> 2. "[PATCH v4] mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY"

Ah, OK, the title of the first patch was changed, which threw me off.

I'd skipped "[PATCH v4] mm, hugetlb: Fix simple resv_huge_pages
underflow on UFFDIO_COPY" because Mike's comments appeared to require a
v5.  I applied it and made Mike's changelog suggestions.  Queued for
5.13 and -stable.

And I queued "[PATCH v4] mm, hugetlb: fix racy resv_huge_pages
underflow on UFFDIO_COPY" for 5.14.



  reply	other threads:[~2021-06-01  0:36 UTC|newest]

Thread overview: 19+ 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-28  0:50 ` Mina Almasry
2021-05-31 23:25 ` Andrew Morton
2021-06-01  0:11   ` Mina Almasry
2021-06-01  0:11     ` Mina Almasry
2021-06-01  0:36     ` Andrew Morton [this message]
2021-06-01  2:48       ` Mina Almasry
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:04             ` Mina Almasry
2021-06-01 18:05             ` 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  1:06     ` Mina Almasry
2021-06-05 12:49     ` [External] " Muchun Song
2021-06-05 12:49       ` 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=20210531173652.c21404a16a8f8542ce40afa8@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.