All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Hugh Dickins <hughd@google.com>,
	Nadav Amit <nadav.amit@gmail.com>
Subject: Re: [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently
Date: Wed, 22 Sep 2021 16:04:44 -0400	[thread overview]
Message-ID: <YUuMXCFbj1mmOKec@t490s> (raw)
In-Reply-To: <CAHbLzkq7kTdEC6ADJRAxXBEOYhsjR8E9uiEFCYFmtA5cD5fMhA@mail.gmail.com>

On Wed, Sep 22, 2021 at 12:29:35PM -0700, Yang Shi wrote:
> khugepqged does remove the pgtables. Please check out
> retract_page_tables(). The pmd will be cleared and the ptes will be
> freed otherwise the collapsed THP won't get PMD mapped by later
> access.

Indeed.

I should probably still properly disable khugepaged for at least VM_SHARED &&
VM_UFFD_WP, then I'd keep the anonymous && minor mode behavior untouched.

The other problem is even if current mm/vma doesn't have UFFD_WP registered,
some other mm/vma could have UFFD_WP enabled there that mapped the same file.
Checking that up within retract_page_tables() on all VMAs seems to be a bit too
late.

Checking it early may not trivially work too - I can walk the vma interval tree
at the entry of khugepaged_scan_file(), making sure no vma has UFFD_WP set.
However I don't see how it'll stop some of the vma from having UFFD_WP
registered later after that point but before retract_page_tables().

I'll need to think about it, but thanks for the input, Yang.  That's a very
important point.

-- 
Peter Xu



  reply	other threads:[~2021-09-22 20:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 17:51 [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently Peter Xu
2021-09-22 18:21 ` David Hildenbrand
2021-09-22 18:58   ` Peter Xu
2021-09-22 19:29     ` Yang Shi
2021-09-22 20:04       ` Peter Xu [this message]
2021-09-22 20:23         ` Peter Xu
2021-09-24 10:05     ` David Hildenbrand
2021-09-22 19:33 ` Peter Xu
2021-09-22 20:49 ` Axel Rasmussen
2021-09-22 21:20   ` Peter Xu
2021-09-22 23:18     ` Hugh Dickins
2021-09-22 23:44       ` Peter Xu
2021-09-23  1:22         ` Hugh Dickins
2021-09-23  2:18           ` Peter Xu
2021-09-23 16:47             ` Axel Rasmussen
2021-09-23 17:53               ` Peter Xu

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=YUuMXCFbj1mmOKec@t490s \
    --to=peterx@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.com \
    --cc=shy828301@gmail.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.