From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Jan Kara <jack@suse.cz>, Kirill Shutemov <kirill@shutemov.name>,
Oleg Nesterov <oleg@redhat.com>, Christoph Hellwig <hch@lst.de>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mike Kravetz <mike.kravetz@oracle.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: [5.4 PATCH] mm/gup: Do not force a COW break on file-backed memory
Date: Wed, 1 Dec 2021 23:17:57 +0000 [thread overview]
Message-ID: <20211201231757.332199-1-willy@infradead.org> (raw)
Commit 17839856fd58 ("gup: document and work around "COW can break either
way" issue") forces a COW break, even for read-only GUP. This interacts
badly with CONFIG_READ_ONLY_THP_FOR_FS as it tries to write to a read-only
PMD and follow_trans_huge_pmd() returns NULL which induces an endless
loop as __get_user_pages() interprets that as page-not-present, tries
to fault it in and retries the follow_page_mask().
The issues fixed by 17839856fd58 don't apply to files. We know which way
the COW breaks; the page cache keeps the original and any modifications
are private to that process. There's no optimisation that allows a
process to reuse a file-backed MAP_PRIVATE page. So we can skip the
breaking of the COW for file-backed mappings.
This problem only exists in v5.4.y; other stable kernels either predate
CONFIG_READ_ONLY_THP_FOR_FS or they include commit a308c71bf1e6 ("mm/gup:
Remove enfornced COW mechanism").
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
mm/gup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index 3ef769529548..d55e02411010 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -176,7 +176,8 @@ static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
*/
static inline bool should_force_cow_break(struct vm_area_struct *vma, unsigned int flags)
{
- return is_cow_mapping(vma->vm_flags) && (flags & FOLL_GET);
+ return is_cow_mapping(vma->vm_flags) && vma_is_anonymous(vma) &&
+ (flags & FOLL_GET);
}
static struct page *follow_page_pte(struct vm_area_struct *vma,
--
2.33.0
next reply other threads:[~2021-12-01 23:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 23:17 Matthew Wilcox (Oracle) [this message]
2021-12-02 3:51 ` Jann Horn
2021-12-02 4:11 ` Matthew Wilcox
2021-12-02 4:33 ` Jann Horn
2021-12-02 18:54 ` Linus Torvalds
2021-12-02 19:59 ` Matthew Wilcox
2021-12-02 22:33 ` 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=20211201231757.332199-1-willy@infradead.org \
--to=willy@infradead.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=oleg@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