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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 F2E1FC4727C for ; Tue, 22 Sep 2020 16:10:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 649E7238D7 for ; Tue, 22 Sep 2020 16:10:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="DQmup5Ia" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 649E7238D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7EE5690004C; Tue, 22 Sep 2020 12:10:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DCA3900059; Tue, 22 Sep 2020 12:10:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6557D90004C; Tue, 22 Sep 2020 12:10:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 460CD90000A for ; Tue, 22 Sep 2020 12:10:50 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id F203F180AD804 for ; Tue, 22 Sep 2020 16:10:49 +0000 (UTC) X-FDA: 77291185860.18.level91_3302b3d2714f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 89638100EDBC9 for ; Tue, 22 Sep 2020 16:10:49 +0000 (UTC) X-HE-Tag: level91_3302b3d2714f X-Filterd-Recvd-Size: 5087 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 16:10:48 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id z2so15958559qtv.12 for ; Tue, 22 Sep 2020 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5Vl0iSMcOXyao6qb+mlx5tyYrlNVljHFBTvCu/sbwcE=; b=DQmup5IacmK0M1JgFhK8SgL6Orwefv8vRSFfd4Utb6UlC/AtTAq3uWvYcoCsPXoO+0 jSHSc/lDrYcODasxoB6mCfSdgciqS9yar5ov7yS/52yEYdaSNz0VR8xVTcbROjBEFo6G zyOiOJgfn2SPh4dvpeK8JyCG4VW8l3kLXNeO8cYku4OlUbhERNC4yuqrCobVzauG4FYt tIr4cp+pW2aVx44S8cDUBH6hRcvDV/gYZ5xKTJvmZ6anyZAeB4PXvOqdljKM72xS4oWf fKDbNqCODLJq2zuD46CWwlDZt0igf5EDNTP+GE9KbGwpB+N6jMBQTLiO7ihOFLoFR7gM Sk9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5Vl0iSMcOXyao6qb+mlx5tyYrlNVljHFBTvCu/sbwcE=; b=KVoqwdJk21Ma+qjqy++gLwYVOgrWlfg1Yk+9nXxZ1W3fUTutqN2i+G51cLz4tmHvJQ sWLsjeUW7IUDQqYUunOiQK5i7T/rREqCPmgVdW30XB6h4lxzDBxiuwQpV4ns8Zqjhb3l MRrqpK7QDN9bPxDaeGdo48fTnqc5jzI67D0fUlmK3YD9VA3Nrvks3zhKEx8q7zrm+t2R FvDoAOnsPGz71RwMM9/5Zz7jb0rdbz/Bka1W1fG13LLpUr4j0w+t0E2xlV71yb/yWFB+ Ql/xJVvSWZXUgCxAZjoasFbzYaAnso2y3kc+YUJFPt55HqqoRjKtGHE8adkRvw386NY8 ksag== X-Gm-Message-State: AOAM532WHW6ddPNnYjBMQzfZQ6M1wNm7AICXk9b5o3tUNNMCtGqhqT8K 36YnJMty1kx4z0fwHPdvYF/pxiiOTcxKC6cp X-Google-Smtp-Source: ABdhPJx3MvXCkuW79dduAHvbtsPt1XZsdujt1v708ppwo5lOljCguasgspUqIMVvVIokdZHpdoWy5Q== X-Received: by 2002:ac8:1a48:: with SMTP id q8mr5508936qtk.240.1600791048289; Tue, 22 Sep 2020 09:10:48 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id 202sm11573021qkg.56.2020.09.22.09.10.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 09:10:47 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kKksQ-0034i7-Mt; Tue, 22 Sep 2020 13:10:46 -0300 Date: Tue, 22 Sep 2020 13:10:46 -0300 From: Jason Gunthorpe To: Peter Xu Cc: John Hubbard , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jan Kara , Michal Hocko , Kirill Tkhai , Kirill Shutemov , Hugh Dickins , Christoph Hellwig , Andrea Arcangeli , Oleg Nesterov , Leon Romanovsky , Linus Torvalds , Jann Horn Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned Message-ID: <20200922161046.GB731578@ziepe.ca> References: <20200921211744.24758-1-peterx@redhat.com> <20200921211744.24758-2-peterx@redhat.com> <224908c1-5d0f-8e01-baa9-94ec2374971f@nvidia.com> <20200922151736.GD19098@xz-x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200922151736.GD19098@xz-x1> 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 Tue, Sep 22, 2020 at 11:17:36AM -0400, Peter Xu wrote: > > But it's admittedly a cosmetic point, combined with my perennial fear that > > I'm missing something when I look at a READ_ONCE()/WRITE_ONCE() pair. :) > > Yeah but I hope I'm using it right.. :) I used READ_ONCE/WRITE_ONCE explicitly > because I think they're cheaper than atomic operations, (which will, iiuc, lock > the bus). It is worth thinking a bit about racing fork with pin_user_pages(). The desired outcome is: If fork wins the page is write protected, and pin_user_pages_fast() will COW it. If pin_user_pages_fast() wins then fork must see the READ_ONCE and the pin. As get_user_pages_fast() is lockless it looks like the ordering has to be like this: pin_user_pages_fast() fork() atomic_set(has_pinned, 1); [..] atomic_add(page->_refcount) ordered check write protect() ordered set write protect() atomic_read(page->_refcount) atomic_read(has_pinned) Such that in all the degenerate racy cases the outcome is that both sides COW, never neither. Thus I think it does have to be atomics purely from an ordering perspective, observing an increased _refcount requires that has_pinned != 0 if we are pinning. So, to make this 100% this ordering will need to be touched up too. Jason