From patchwork Sat Oct 24 00:19:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 11854659 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E911E61C for ; Sat, 24 Oct 2020 00:19:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 88BE520936 for ; Sat, 24 Oct 2020 00:19:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="GMcQyh5I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88BE520936 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 B70C76B005C; Fri, 23 Oct 2020 20:19:26 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id B48156B0068; Fri, 23 Oct 2020 20:19:26 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A45076B006C; Fri, 23 Oct 2020 20:19:26 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 6E5276B005C for ; Fri, 23 Oct 2020 20:19:26 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 168E8181AEF09 for ; Sat, 24 Oct 2020 00:19:26 +0000 (UTC) X-FDA: 77404909932.07.deer81_2d093aa2725d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id EB7B11803F9A8 for ; Sat, 24 Oct 2020 00:19:25 +0000 (UTC) X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,jgg@nvidia.com,,RULES_HIT:30054:30064:30070:30090,0,RBL:216.228.121.64:@nvidia.com:.lbl8.mailshell.net-64.10.201.10 62.18.0.100;04yggwtgxkz9eo7esh6f9zu3wy4j4oc56ydsdenti9pugww5hjeth65d3184dsk.r9ue3s4yxj9iqiguh6gspj7biyq4smprbgfmhseoer7t9rejsebb3f6b76hcwkj.1-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:ft,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: deer81_2d093aa2725d X-Filterd-Recvd-Size: 10756 Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Sat, 24 Oct 2020 00:19:25 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Fri, 23 Oct 2020 17:19:29 -0700 Received: from HQMAIL107.nvidia.com (172.20.187.13) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 24 Oct 2020 00:19:23 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.175) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 24 Oct 2020 00:19:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ib/Ms4L++9AoBl0Wh3KMHU39IxP8rbE+tyOqSeqZF+mrBTf/9zDxeVNLGVurBC6VOD/MoXBa/7pVk3wJwyoCQAizbyVQ8T4YZp+QABG1BrdY1ieM+9dRA1yrnn5jLJtneJCBUF9vtox0X/ldq1glamjfaJ0SCi7ocg7K+b0CbBSh61rd9Wvtm9YD2M/dctBpVfEUfSUVKGdrNz9MqWg/+So6WjQGX+u7E2uaoPTP77R9S2+drH//dP1fjs8KNVCLp4T8kZCVb7SgWK1N7/m3QRxaKHXIGNaD75pfBRh0/L7rAp2ciys3E3S3FZTnFus18hKVpQ3eFXs/jFDSSPJFaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kMOFlwEYFb63qJBhsu9FQ9FOf49aOByswFlBBFw7UX0=; b=Zx3ZSSIybj6Ze+j6jDmqOvvwZZFQ8Fe7O69oWhexFhQ+mUhE2Ss4HKTsh3TuUiuBgKpR9+4xLVxBOHp3DDDFSpWELNuT040CNd9QAuCyYUZ2oSEhl9zk8ykuAmk9psrXjgylvaSjj9o5Zjd1YwsFz6FRwC9DKEw0eTe3N7Gnmd7qVdylRt6Fup7ayOlNfNomSXDoFMkG1Ek0eMcZhpjZEAmK8115CCIexbIxSM68+KpA9CqJ/2+Kxy+G4nb7a5+BkJc9Hy7M2LUJIuawsJDEj38PvhIr2t6O05b4d5hJGsU33ol53yUH0DfgDKFHRh/C4TmrZI8B6y2hDKzNwJh4gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from DM6PR12MB3834.namprd12.prod.outlook.com (2603:10b6:5:14a::12) by DM6PR12MB4299.namprd12.prod.outlook.com (2603:10b6:5:223::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Sat, 24 Oct 2020 00:19:22 +0000 Received: from DM6PR12MB3834.namprd12.prod.outlook.com ([fe80::cdbe:f274:ad65:9a78]) by DM6PR12MB3834.namprd12.prod.outlook.com ([fe80::cdbe:f274:ad65:9a78%7]) with mapi id 15.20.3477.028; Sat, 24 Oct 2020 00:19:22 +0000 From: Jason Gunthorpe To: CC: Andrea Arcangeli , Andrew Morton , Aneesh Kumar K.V , Christoph Hellwig , Hugh Dickins , Jan Kara , Jann Horn , John Hubbard , Kirill Shutemov , Kirill Tkhai , Leon Romanovsky , Linux-MM , Michal Hocko , Oleg Nesterov , Peter Xu , Linus Torvalds Subject: [PATCH 2/2] mm: prevent gup_fast from racing with COW during fork Date: Fri, 23 Oct 2020 21:19:20 -0300 Message-ID: <2-v1-281e425c752f+2df-gup_fork_jgg@nvidia.com> In-Reply-To: <0-v1-281e425c752f+2df-gup_fork_jgg@nvidia.com> References: X-ClientProxiedBy: MN2PR16CA0065.namprd16.prod.outlook.com (2603:10b6:208:234::34) To DM6PR12MB3834.namprd12.prod.outlook.com (2603:10b6:5:14a::12) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mlx.ziepe.ca (156.34.48.30) by MN2PR16CA0065.namprd16.prod.outlook.com (2603:10b6:208:234::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Sat, 24 Oct 2020 00:19:21 +0000 Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kW7HE-0076cz-BU; Fri, 23 Oct 2020 21:19:20 -0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603498769; bh=sp6IwlI2DD7xpyWqHmTSQyZ70NylysQOCZbrqFYZpOI=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To: CC:Subject:Date:Message-ID:In-Reply-To:References: Content-Transfer-Encoding:Content-Type:X-ClientProxiedBy: MIME-Version:X-MS-Exchange-MessageSentRepresentingType; b=GMcQyh5I2v29609kpOC1BGlZ7lbBzVbg8SzpnN8CeK9P42+DBw9V/3CTEOl/Cue0S Ij8WTnDLbCG0LFt2xR/q0Nz1UMK5MSlpTeYac6IR2uVhlU8DU4qkVONhFj69ivycQL O5JHclsURVPFd1FtZyExEnum5Mr9+s+d1G6jIxx04RWNGoBnZsy4YhPvWQI9TEjh8P rA9fU8dXdXkvsoZ5MH95XLW4wbWOucc7c8lT2BRzq3+Ir3Nc2ihYgqEUV45alfE3rD q0b+hEfD8cjz07A1GksbBwT8Hzck/TpSmAuiS44zhzYyXc4RjgrfyCXze6FMjJuAL0 idEqWRCaBdWag== 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: 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 Reviewed-by: John Hubbard Reported-by: kernel test robot --- 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 + * 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) { + 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(); } 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; }