From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A172C2D0A3 for ; Sat, 24 Oct 2020 05:19:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CAF7622273 for ; Sat, 24 Oct 2020 05:19:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="aUXbU1Yx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAF7622273 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2423C6B0062; Sat, 24 Oct 2020 01:19:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F29D6B0068; Sat, 24 Oct 2020 01:19:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E2FF6B006C; Sat, 24 Oct 2020 01:19:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id D5AC66B0062 for ; Sat, 24 Oct 2020 01:19:41 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 614F6180AD81A for ; Sat, 24 Oct 2020 05:19:41 +0000 (UTC) X-FDA: 77405666562.14.card02_1e085652725f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 466AE18229818 for ; Sat, 24 Oct 2020 05:19:41 +0000 (UTC) X-HE-Tag: card02_1e085652725f X-Filterd-Recvd-Size: 9815 Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Sat, 24 Oct 2020 05:19:40 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Fri, 23 Oct 2020 22:19:48 -0700 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 24 Oct 2020 05:19:39 +0000 Received: from [10.2.51.100] (10.124.1.5) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 24 Oct 2020 05:19:38 +0000 Subject: Re: [PATCH 2/2] mm: prevent gup_fast from racing with COW during fork To: Jason Gunthorpe , CC: Andrea Arcangeli , Andrew Morton , Aneesh Kumar K.V , Christoph Hellwig , Hugh Dickins , Jan Kara , Jann Horn , Kirill Shutemov , Kirill Tkhai , Leon Romanovsky , Linux-MM , Michal Hocko , Oleg Nesterov , Peter Xu , Linus Torvalds References: <2-v1-281e425c752f+2df-gup_fork_jgg@nvidia.com> From: John Hubbard Message-ID: Date: Fri, 23 Oct 2020 22:19:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2-v1-281e425c752f+2df-gup_fork_jgg@nvidia.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To DRHQMAIL107.nvidia.com (10.27.9.16) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603516788; bh=mXpWHZS6f92xRrp99tnpgc+E0NtnsTCwKRBcfuiTwk4=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=aUXbU1Yxg01tv0zIf4kg8Ug5r51oRliEqBuouDDto8rnabusLndYGJVURpqJybtIv W7/zHN0LJSbc2G308uqoEG1s7LnQ+nOM0XKEJBPTsI0c3PhbwMpinIWl41Bsgw+pOD DP3AU1qBhkSAMlQr5URI28/fGUFBcNXEFdLqPY4t16HY7Dm2/e165HKIexSfu1Mlxm V3ajwLxSlizVls0CBNu409G/mNL7uqaHmTOYTX3C7NkE+aQCrNxZRtV/rWktLO1Z/m xseyY79NcJCw8XKq+FNvdap9L8QtKWlUUSaCdM6x2IUwE//lpWJBqnqb6VKZj8BuLF jyKQH0BJdjCMA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/23/20 5:19 PM, Jason Gunthorpe wrote: > Since commit 70e806e4e645 ("mm: Do early cow for pinned pages during > fork() for ptes") pages under a FOLL_PIN will not be write protected > during COW for fork. This means that pages returned from > pin_user_pages(FOLL_WRITE) should not become write protected while the pin > is active. > > However, there is a small race where get_user_pages_fast(FOLL_PIN) can > establish a FOLL_PIN at the same time copy_present_page() is write > protecting it: > > CPU 0 CPU 1 > get_user_pages_fast() > internal_get_user_pages_fast() > copy_page_range() > pte_alloc_map_lock() > copy_present_page() > atomic_read(has_pinned) == 0 > page_maybe_dma_pinned() == false > atomic_set(has_pinned, 1); > gup_pgd_range() > gup_pte_range() > pte_t pte = gup_get_pte(ptep) > pte_access_permitted(pte) > try_grab_compound_head() > pte = maybe_mkwrite() > set_pte_at(); > pte_unmap_unlock() > // GUP now returns with a write protected page > > The first attempt to resolve this by using the write protect caused > problems (and was missing a barrrier), see commit f3c64eda3e50 ("mm: avoid > early COW write protect games during fork()") > > Instead wrap copy_p4d_range() with the write side of something like a > seqcount and check the read side around gup_pgd_range(). If there is a > collision then get_user_pages_fast() fails and falls back to slow GUP. > > Slow GUP is safe against this race because copy_page_range() is only > called while holding the write side of the mmap_lock on the src mm_struct. > > Fixes: f3c64eda3e50 ("mm: avoid early COW write protect games during fork()") > Suggested-by: Linus Torvalds > Link: https://lore.kernel.org/r/CAHk-=wi=iCnYCARbPGjkVJu9eyYeZ13N64tZYLdOB8CP5Q_PLw@mail.gmail.com > Signed-off-by: Jason Gunthorpe > --- > include/linux/mm_types.h | 6 ++++++ > kernel/fork.c | 1 + > mm/gup.c | 19 +++++++++++++++++++ > mm/memory.c | 16 +++++++++++++++- > 4 files changed, 41 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 5a9238f6caad97..8c7c9de476c4f8 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -446,6 +446,12 @@ struct mm_struct { > */ > atomic_t has_pinned; > > + /** > + * @write_protecet_seq: Odd when any thread is write typo, make that: @write_protect_seq Given that this is an open-coded seqlock-like thing, I think it deserves quite a bit more comment. Maybe something like the comment that you already drafted for memory.c. But as I mentioned in the reply to the cover letter, what I'd really prefer is just using the raw seqlock API. I really-really-really think it's better for the situation, than doing it this way. > + * protecting pages in this mm, for instance during fork(). > + */ > + unsigned long write_protect_seq; > + > #ifdef CONFIG_MMU > atomic_long_t pgtables_bytes; /* PTE page table pages */ > #endif > diff --git a/kernel/fork.c b/kernel/fork.c > index 32083db7a2a23e..342243f621c742 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1007,6 +1007,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p, > mm->vmacache_seqnum = 0; > atomic_set(&mm->mm_users, 1); > atomic_set(&mm->mm_count, 1); > + mm->write_protect_seq = 0; > mmap_init_lock(mm); > INIT_LIST_HEAD(&mm->mmlist); > mm->core_state = NULL; > diff --git a/mm/gup.c b/mm/gup.c > index ecbe1639ea2af7..2c1a1e0555479e 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -2677,12 +2677,19 @@ static unsigned int lockless_pages_from_mm(unsigned long addr, > struct page **pages) > { > unsigned long flags; > + unsigned long seq; > int nr_pinned = 0; > > if (!IS_ENABLED(CONFIG_HAVE_FAST_GUP) || > !gup_fast_permitted(addr, end)) > return 0; > > + if (gup_flags & FOLL_PIN) { > + seq = smp_load_acquire(¤t->mm->write_protect_seq); > + if (seq & 1) > + return 0; > + } > + > /* > * Disable interrupts. The nested form is used, in order to allow full, > * general purpose use of this routine. > @@ -2697,6 +2704,18 @@ static unsigned int lockless_pages_from_mm(unsigned long addr, > local_irq_save(flags); > gup_pgd_range(addr, end, gup_flags, pages, &nr_pinned); > local_irq_restore(flags); > + > + /* > + * When pinning pages for DMA there could be a concurrent write protect > + * from fork() via copy_page_range(), in this case always fail fast GUP. > + */ > + if (gup_flags & FOLL_PIN) { > + smp_rmb(); > + if (READ_ONCE(current->mm->write_protect_seq) != seq) { So, above we use smp_load_acquire() to read this, but here we use use smp_rmb() plus READ_ONCE(). OK, I am in over my head, even with memory-barriers.txt. :) Hopefully someone with skill in this area can help review that. > + unpin_user_pages(pages, nr_pinned); > + return 0; > + } > + } > return nr_pinned; > } > > diff --git a/mm/memory.c b/mm/memory.c > index c48f8df6e50268..e2f959cce8563d 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1171,6 +1171,17 @@ copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) > mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_PAGE, > 0, src_vma, src_mm, addr, end); > mmu_notifier_invalidate_range_start(&range); > + /* > + * This is like a seqcount where the mmap_lock provides > + * serialization for the write side. However, unlike seqcount > + * the read side falls back to obtaining the mmap_lock rather > + * than spinning. For this reason none of the preempt related > + * machinery in seqcount is desired here. > + */ > + mmap_assert_write_locked(src_mm); > + WRITE_ONCE(src_mm->write_protect_seq, > + src_mm->write_protect_seq + 1); > + smp_wmb(); Even if you don't take the "use the raw seqlock API" advice, it seems like these operations could be wrapped up in a function call, yes? thanks, -- John Hubbard NVIDIA > } > > ret = 0; > @@ -1187,8 +1198,11 @@ copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) > } > } while (dst_pgd++, src_pgd++, addr = next, addr != end); > > - if (is_cow) > + if (is_cow) { > + smp_store_release(&src_mm->write_protect_seq, > + src_mm->write_protect_seq + 1); > mmu_notifier_invalidate_range_end(&range); > + } > return ret; > } > >