From: Jann Horn <jannh@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: Linux-MM <linux-mm@kvack.org>,
kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Marty Mcfadden <mcfadden8@llnl.gov>,
"Maya B . Gokhale" <gokhale2@llnl.gov>,
Andrea Arcangeli <aarcange@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>, Oleg Nesterov <oleg@redhat.com>,
Kirill Shutemov <kirill@shutemov.name>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v3] mm/gup: Allow real explicit breaking of COW
Date: Tue, 11 Aug 2020 21:07:17 +0200 [thread overview]
Message-ID: <CAG48ez0dJh=-J2RNcam4Q353Lq_ZT+kfkHzTKGgwCvea-eQLqg@mail.gmail.com> (raw)
In-Reply-To: <20200811183950.10603-1-peterx@redhat.com>
On Tue, Aug 11, 2020 at 8:39 PM Peter Xu <peterx@redhat.com> wrote:
> Starting from commit 17839856fd58 ("gup: document and work around "COW can
> break either way" issue", 2020-06-02), explicit copy-on-write behavior is
> enforced for private gup pages even if it's a read-only. It is achieved by
> always passing FOLL_WRITE to emulate a write.
>
> That should fix the COW issue that we were facing, however above commit could
> also break userfaultfd-wp and applications like umapsort [1,2].
>
> One general routine of umap-like program is: userspace library will manage page
> allocations, and it will evict the least recently used pages from memory to
> external storages (e.g., file systems). Below are the general steps to evict
> an in-memory page in the uffd service thread when the page pool is full:
>
> (1) UFFDIO_WRITEPROTECT with mode=WP on some to-be-evicted page P, so that
> further writes to page P will block (keep page P clean)
> (2) Copy page P to external storage (e.g. file system)
> (3) MADV_DONTNEED to evict page P
>
> Here step (1) makes sure that the page to dump will always be up-to-date, so
> that the page snapshot in the file system is consistent with the one that was
> in the memory. However with commit 17839856fd58, step (2) can potentially hang
> itself because e.g. if we use write() to a file system fd to dump the page
> data, that will be a translated read gup request in the file system driver to
> read the page content, then the read gup will be translated to a write gup due
> to the new enforced COW behavior. This write gup will further trigger
> handle_userfault() and hang the uffd service thread itself.
>
> I think the problem will go away too if we replace the write() to the file
> system into a memory write to a mmaped region in the userspace library, because
> normal page faults will not enforce COW, only gup is affected. However we
> cannot forbid users to use write() or any form of kernel level read gup.
>
> One solution is actually already mentioned in commit 17839856fd58, which is to
> provide an explicit BREAK_COW scemantics for enforced COW. Then we can still
> use FAULT_FLAG_WRITE to identify whether this is a "real write request" or an
> "enfornced COW (read) request".
>
> With the enforced COW, we also need to inherit UFFD_WP bit during COW because
> now COW can happen with UFFD_WP enabled (previously, it cannot).
>
> Since at it, rename the variable in __handle_mm_fault() from "dirty" to "cow"
> to better suite its functionality.
[...]
> diff --git a/mm/memory.c b/mm/memory.c
[...]
> + * copied due to enfornced COW. When it happens, we
(typo here and in the huge_memory version)
[...]
> diff --git a/mm/gup.c b/mm/gup.c
> index d8a33dd1430d..c33e84ab9c36 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -870,6 +870,8 @@ static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
> return -ENOENT;
> if (*flags & FOLL_WRITE)
> fault_flags |= FAULT_FLAG_WRITE;
> + if (*flags & FOLL_BREAK_COW)
> + fault_flags |= FAULT_FLAG_BREAK_COW;
> if (*flags & FOLL_REMOTE)
> fault_flags |= FAULT_FLAG_REMOTE;
> if (locked)
> @@ -1076,7 +1078,7 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> }
> if (is_vm_hugetlb_page(vma)) {
> if (should_force_cow_break(vma, foll_flags))
> - foll_flags |= FOLL_WRITE;
> + foll_flags |= FOLL_BREAK_COW;
How does this interact with the FOLL_WRITE check in follow_page_pte()?
If we want the COW to be broken, follow_page_pte() would have to treat
FOLL_BREAK_COW similarly to FOLL_WRITE, right?
next prev parent reply other threads:[~2020-08-11 19:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 18:39 [PATCH v3] mm/gup: Allow real explicit breaking of COW Peter Xu
2020-08-11 19:07 ` Jann Horn [this message]
2020-08-11 20:02 ` Peter Xu
2020-08-11 20:22 ` Jann Horn
2020-08-11 21:23 ` Peter Xu
2020-08-11 19:24 ` Linus Torvalds
2020-08-11 20:06 ` Linus Torvalds
2020-08-11 20:46 ` Linus Torvalds
2020-08-11 21:42 ` Peter Xu
2020-08-11 23:10 ` Linus Torvalds
2020-08-20 21:54 ` Peter Xu
2020-08-20 22:01 ` Linus Torvalds
2020-08-21 10:13 ` Jan Kara
2020-08-21 12:27 ` Linus Torvalds
2020-08-21 15:47 ` Jan Kara
2020-08-21 17:00 ` Linus Torvalds
2020-08-21 18:08 ` Peter Xu
2020-08-21 18:23 ` Linus Torvalds
2020-08-21 19:05 ` Linus Torvalds
2020-08-21 19:06 ` Linus Torvalds
2020-08-21 19:31 ` Peter Xu
2020-08-21 19:42 ` Linus Torvalds
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='CAG48ez0dJh=-J2RNcam4Q353Lq_ZT+kfkHzTKGgwCvea-eQLqg@mail.gmail.com' \
--to=jannh@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=gokhale2@llnl.gov \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcfadden8@llnl.gov \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
--cc=torvalds@linux-foundation.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).