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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 ACE67C00A89 for ; Mon, 2 Nov 2020 08:31:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B44D2231B for ; Mon, 2 Nov 2020 08:31:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728234AbgKBIbY (ORCPT ); Mon, 2 Nov 2020 03:31:24 -0500 Received: from mx2.suse.de ([195.135.220.15]:46542 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727802AbgKBIbY (ORCPT ); Mon, 2 Nov 2020 03:31:24 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8DF84AAF1; Mon, 2 Nov 2020 08:31:22 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 32EC01E12FB; Mon, 2 Nov 2020 09:31:22 +0100 (CET) Date: Mon, 2 Nov 2020 09:31:22 +0100 From: Jan Kara To: Jason Gunthorpe Cc: Jan Kara , linux-kernel@vger.kernel.org, Peter Xu , Linus Torvalds , Andrea Arcangeli , Andrew Morton , "Aneesh Kumar K.V" , Christoph Hellwig , Hugh Dickins , Jann Horn , John Hubbard , Kirill Shutemov , Kirill Tkhai , Leon Romanovsky , Linux-MM , Michal Hocko , Oleg Nesterov Subject: Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork Message-ID: <20201102083122.GA23988@quack2.suse.cz> References: <0-v2-dfe9ecdb6c74+2066-gup_fork_jgg@nvidia.com> <2-v2-dfe9ecdb6c74+2066-gup_fork_jgg@nvidia.com> <20201030165105.GH19757@quack2.suse.cz> <20201030170226.GF2620339@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201030170226.GF2620339@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-10-20 14:02:26, Jason Gunthorpe wrote: > On Fri, Oct 30, 2020 at 05:51:05PM +0100, Jan Kara wrote: > > > @@ -446,6 +447,12 @@ struct mm_struct { > > > */ > > > atomic_t has_pinned; > > > > > > + /** > > > + * @write_protect_seq: Odd when any thread is write protecting > > > + * pages in this mm, for instance during fork(). > > > + */ > > > + seqcount_t write_protect_seq; > > > + > > > > So this comment isn't quite true. We can be writeprotecting pages due to > > many other reasons and not touch write_protect_seq. E.g. for shared > > mappings or due to explicit mprotect() calls. So the write_protect_seq > > protection has to be about something more than pure write protection. One > > requirement certainly is that the VMA has to be is_cow_mapping(). What > > about mprotect(2) calls? I guess the application would have only itself to > > blame so we don't care? > > Yes, that sounds right, How about > > /** > * @write_protect_seq: Locked when any thread is write protecting > * pages for COW in this mm, for instance during page table copying ^^^ maybe I'd write a bit more explicitly "... write protecting pages mapped by this mm to enforce later COW, ..." > * for fork(). > */ > > mprotect and shared mappings cause faults on write access not COW? Correct. Honza -- Jan Kara SUSE Labs, CR