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=-6.9 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,MSGID_FROM_MTA_HEADER,SPF_HELO_NONE, SPF_PASS autolearn=no 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 A25B0C56201 for ; Mon, 26 Oct 2020 23:50:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2FD4F21741 for ; Mon, 26 Oct 2020 23:50:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="VbVRLc2T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FD4F21741 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 4D3566B005C; Mon, 26 Oct 2020 19:50:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 482A06B005D; Mon, 26 Oct 2020 19:50:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3719E6B0062; Mon, 26 Oct 2020 19:50:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 0793F6B005C for ; Mon, 26 Oct 2020 19:50:03 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 81D9D181AC9CC for ; Mon, 26 Oct 2020 23:50:03 +0000 (UTC) X-FDA: 77415722286.03.cars59_040e17927277 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 6295F28A4E8 for ; Mon, 26 Oct 2020 23:50:03 +0000 (UTC) X-HE-Tag: cars59_040e17927277 X-Filterd-Recvd-Size: 7294 Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Oct 2020 23:50:01 +0000 (UTC) Received: from HKMAIL104.nvidia.com (Not Verified[10.18.92.77]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Tue, 27 Oct 2020 07:49:58 +0800 Received: from HKMAIL104.nvidia.com (10.18.16.13) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Oct 2020 23:49:57 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Oct 2020 23:49:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nyyrfjZmAodF/sjXp4QWywRJcljxZlaZoXu593WE2VT3gn02vO0upydUiJVcFDQ9T3BN+8LjO0odUnoDc1xpM+4+72urd7cML75zTcWyKlhtkn7kBMP0qWX20DgGgD1WGU3yJfF7J4Ow1YK231bdzHjo0r2ZKUzhlhNKkluoBeLKc0oMle/WVlAX1EImPWcAcz/Q0SQT664TqBAn2JK2twqySL1DSo6FHixJpL6VuT5ims2dqyN0hjUJUdYNOLAHPKOv8Q+T7oDZ0s8x3qNHQUy0YX8YoE7EEouMRYeHGEEZs8t7ciJlMQhZgyRXC99OU36ivphhBT9Sjb8qCRdhyA== 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=MdllUoYbfK4Ax6p2EaWpMmN47dDMf42n9JX23HAF7oA=; b=MSM22d4wdhAP6AJ+FOoQ7HlP9gc48WzB3TJDW144Ehp2zFD/FUWa1Xp6XaI8c+yBnRs7nPX847nRoxvJvDhyudkerxedhRebC6shUgJeBlBfMXyVeK5RE58tGalATdM6P8/pEMz7qWAxhM9ogCPnKBQwmsT6y0Qqm701kt4pyAgtj7Zh1L2nCvxymhoOfidjbwJ/UJG3SlMi0mTNgEgmPKBG7ipfxsd/Z0L1Nrt8Mqiy/HZBw/tc/Jbtf8IrTbic1ic/mDeX3OwS6e+Vrezl4ppX6vG9aZZfqFyvAGoPhnl6Dypynedg+WjxUOFby2RHsqLhbBcggHGTe5qNxK2uhA== 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 DM5PR12MB1516.namprd12.prod.outlook.com (2603:10b6:4:5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Mon, 26 Oct 2020 23:49:54 +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; Mon, 26 Oct 2020 23:49:54 +0000 Date: Mon, 26 Oct 2020 20:49:52 -0300 From: Jason Gunthorpe To: John Hubbard 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 Subject: Re: [PATCH 2/2] mm: prevent gup_fast from racing with COW during fork Message-ID: <20201026234952.GD1523783@nvidia.com> References: <2-v1-281e425c752f+2df-gup_fork_jgg@nvidia.com> <32a38d92-6ecc-243b-77be-8f1ea0792334@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <32a38d92-6ecc-243b-77be-8f1ea0792334@nvidia.com> X-ClientProxiedBy: YT1PR01CA0145.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:2f::24) 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 (206.223.160.26) by YT1PR01CA0145.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:2f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22 via Frontend Transport; Mon, 26 Oct 2020 23:49:54 +0000 Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kXCFM-0094w6-Nd; Mon, 26 Oct 2020 20:49:52 -0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603756198; bh=dY+4G+rYhb1BzI6Wi/9MKyn4wl9j5wdVzFpKPJ64mss=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:Date: From:To:CC:Subject:Message-ID:References:Content-Type: Content-Disposition:Content-Transfer-Encoding:In-Reply-To: X-ClientProxiedBy:MIME-Version: X-MS-Exchange-MessageSentRepresentingType; b=VbVRLc2TlYGVJqEUNc6+XvsqhC+bzNLJAljZ2EW4O/im+NXsf+4wiZpAL8dmMkK3c HZ7Qm6Rq/FbbXW/Sa6gfym0usJb2IucxEKuGxCoXzaqQd7MetreZGI3F9KY9nPbe0J HIH8z1bJyu1Ef37+bKg9/+un6iT0xPSTqlIe03SCdQ9AhNQ3RJIV3XiWyMsIFnNjed 64rgHk1mop7diLqraGYKwlcNGXLadj+MSJmbhVyk3JXggSRbmX/Gg/HTMFYGnbARQ/ W9ih2m/RHGjEJo3WC7ntlWo3X5Zst7zl5S4HGNaWYl0cvXTkrvOjc09/OJbjTnkJ6i S9GwnCsbzmE0w== 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 Fri, Oct 23, 2020 at 10:31:51PM -0700, John Hubbard wrote: > On 10/23/20 10:19 PM, John Hubbard wrote: > > On 10/23/20 5:19 PM, Jason Gunthorpe wrote: > ... > > > 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) > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mmu_notifier_r= ange_init(&range, MMU_NOTIFY_PROTECTION_PAGE, > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0, src_vma, src_m= m, addr, end); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mmu_notifier_i= nvalidate_range_start(&range); > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This is like a se= qcount where the mmap_lock provides > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * serialization for= the write side. However, unlike seqcount > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * the read side fal= ls back to obtaining the mmap_lock rather > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * than spinning. Fo= r this reason none of the preempt related > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * machinery in seqc= ount is desired here. >=20 > ooops...actually, that's a counter-argument to using the raw seqlock API.= So > maybe that's a dead end, after all. Right, it isn't a "seqcount" because the read side doesn't spin. If this uses the raw seqcount API then every touch uses the raw API. I checked and there is no place else in the kernel using the raw side.. > If so, it would still be good to wrap the "acquire" and "release" > parts of this into functions, IMHO. So we'd end up with, > effectively, a lock API anyway. What it really needs is a smp_load_mb() to match the existing smp_store_mb(= ), then this implementation wouldn't look so odd. It is actually really straightforwad since the write side is under the exclusive mmap_lock. Jason