linux-kernel - Re: [5.4 PATCH] mm/gup: Do not force a COW break on file-backed memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG48ez3YNCNZB7AktmRoYLsBQjwBdwueRUXbkFgNVMsgjmCTGA@mail.gmail.com>
Date:   Thu, 2 Dec 2021 04:51:47 +0100
From:   Jann Horn <jannh@...gle.com>
To:     "Matthew Wilcox (Oracle)" <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        Kirill Shutemov <kirill@...temov.name>,
        Oleg Nesterov <oleg@...hat.com>,
        Christoph Hellwig <hch@....de>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Mike Kravetz <mike.kravetz@...cle.com>
Subject: Re: [5.4 PATCH] mm/gup: Do not force a COW break on file-backed memory

On Thu, Dec 2, 2021 at 12:18 AM Matthew Wilcox (Oracle)
<willy@...radead.org> wrote:
> 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@...radead.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);
>  }

To be fully correct, the check would have to check for PageAnon(), not
whether the mapping is anonymous, right? Since a private file mapping
can still contain anonymous pages from a prior CoW?