linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Yang Shi <shy828301@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] mm/khugepaged: skip shmem with userfaultfd
Date: Tue, 21 Feb 2023 17:12:50 -0500	[thread overview]
Message-ID: <Y/VB4pSCoJMQQn5o@x1n> (raw)
In-Reply-To: <20230217085439.2826375-3-stevensd@google.com>

On Fri, Feb 17, 2023 at 05:54:38PM +0900, David Stevens wrote:
> From: David Stevens <stevensd@chromium.org>
> 
> Make sure that collapse_file respects any userfaultfds registered with
> MODE_MISSING. If userspace has any such userfaultfds registered, then
> for any page which it knows to be missing, it may expect a
> UFFD_EVENT_PAGEFAULT. This means collapse_file needs to be careful when
> collapsing a shmem range would result in replacing an empty page with a
> THP, to avoid breaking userfaultfd.
> 
> Synchronization when checking for userfaultfds in collapse_file is
> tricky because the mmap locks can't be used to prevent races with the
> registration of new userfaultfds. Instead, we provide synchronization by
> ensuring that userspace cannot observe the fact that pages are missing
> before we check for userfaultfds. Although this allows registration of a
> userfaultfd to race with collapse_file, it ensures that userspace cannot
> observe any pages transition from missing to present after such a race
> occurs. This makes such a race indistinguishable to the collapse
> occurring immediately before the userfaultfd registration.
> 
> The first step to provide this synchronization is to stop filling gaps
> during the loop iterating over the target range, since the page cache
> lock can be dropped during that loop. The second step is to fill the
> gaps with XA_RETRY_ENTRY after the page cache lock is acquired the final
> time, to avoid races with accesses to the page cache that only take the
> RCU read lock.
> 
> The fact that we don't fill holes during the initial iteration means
> that collapse_file now has to handle faults occurring during the
> collapse. This is done by re-validating the number of missing pages
> after acquiring the page cache lock for the final time.
> 
> This fix is targeted at khugepaged, but the change also applies to
> MADV_COLLAPSE. MADV_COLLAPSE on a range with a userfaultfd will now
> return EBUSY if there are any missing pages (instead of succeeding on
> shmem and returning EINVAL on anonymous memory). There is also now a
> window during MADV_COLLAPSE where a fault on a missing page will cause
> the syscall to fail with EAGAIN.
> 
> The fact that intermediate page cache state can no longer be observed
> before the rollback of a failed collapse is also technically a
> userspace-visible change (via at least SEEK_DATA and SEEK_END), but it
> is exceedingly unlikely that anything relies on being able to observe
> that transient state.
> 
> Signed-off-by: David Stevens <stevensd@chromium.org>

It'll be great to have another eye looking, but... AFAICT this works for
us.  Thanks David, this is better than what I suggested.

Acked-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu



  reply	other threads:[~2023-02-21 22:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  8:54 [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races David Stevens
2023-02-17  8:54 ` [PATCH v4 1/3] mm/khugepaged: refactor collapse_file control flow David Stevens
2023-02-17 23:44   ` Yang Shi
2023-02-21 21:54   ` Peter Xu
2023-02-21 22:28     ` Yang Shi
2023-02-22  4:08     ` David Stevens
2023-02-22 16:24       ` Peter Xu
2023-02-17  8:54 ` [PATCH v4 2/3] mm/khugepaged: skip shmem with userfaultfd David Stevens
2023-02-21 22:12   ` Peter Xu [this message]
2023-02-17  8:54 ` [PATCH v4 3/3] mm/khugepaged: maintain page cache uptodate flag David Stevens
2023-02-21 22:18   ` Peter Xu
2023-02-17 10:37 ` [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races Miko Larsson
2023-03-03 15:35 ` Peter Xu
2023-03-03 15:45   ` Zach O'Keefe
2023-03-03 18:55   ` Yang Shi
2023-03-03 22:52   ` Andrew Morton
2023-03-06  2:44     ` David Stevens
2023-03-06 21:25       ` Andrew Morton

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=Y/VB4pSCoJMQQn5o@x1n \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shy828301@gmail.com \
    --cc=stevensd@chromium.org \
    --cc=willy@infradead.org \
    /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).