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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,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 9AB69C2BB1D for ; Tue, 14 Apr 2020 19:39:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 570FA20656 for ; Tue, 14 Apr 2020 19:39:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 570FA20656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 054FA8E0012; Tue, 14 Apr 2020 15:39:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1F6C8E0001; Tue, 14 Apr 2020 15:39:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0E6B8E0012; Tue, 14 Apr 2020 15:39:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id C663E8E0001 for ; Tue, 14 Apr 2020 15:39:55 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 83EA5185D for ; Tue, 14 Apr 2020 19:39:55 +0000 (UTC) X-FDA: 76707475950.18.bells10_1c5e70c7f5f4c X-HE-Tag: bells10_1c5e70c7f5f4c X-Filterd-Recvd-Size: 3516 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 19:39:54 +0000 (UTC) IronPort-SDR: RpprqCwAtNDBdEYZFMF+rFkZ1qKSls09+v5SbvX5KuTD9DFV2ZKEWJqZwLRXDNfW2Utv4gcIpB qQ2J1bzUwaPg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2020 12:39:53 -0700 IronPort-SDR: jwBrX7DN0JzzBuuEtGDysHoEvsUWmL3iCQ9lRJ3paKFP8WejhWaNT7aV8D+b7r6QtnNSTXCBDR 1utJOvtdJe3w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,384,1580803200"; d="scan'208";a="245503305" Received: from iweiny-desk2.sc.intel.com ([10.3.52.147]) by fmsmga008.fm.intel.com with ESMTP; 14 Apr 2020 12:39:53 -0700 Date: Tue, 14 Apr 2020 12:39:53 -0700 From: Ira Weiny To: Jason Gunthorpe Cc: Alexander Gordeev , linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , linux-mm@kvack.org Subject: Re: [PATCH] mm/gup: dereference page table entry using helper Message-ID: <20200414193952.GC1853609@iweiny-DESK2.sc.intel.com> References: <1586877001-19138-1-git-send-email-agordeev@linux.ibm.com> <20200414163234.GG5100@ziepe.ca> <20200414185829.GB1853609@iweiny-DESK2.sc.intel.com> <20200414190620.GJ5100@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200414190620.GJ5100@ziepe.ca> User-Agent: Mutt/1.11.1 (2018-12-01) 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, Apr 14, 2020 at 04:06:20PM -0300, Jason Gunthorpe wrote: > On Tue, Apr 14, 2020 at 11:58:29AM -0700, Ira Weiny wrote: > > On Tue, Apr 14, 2020 at 01:32:34PM -0300, Jason Gunthorpe wrote: > > > On Tue, Apr 14, 2020 at 05:10:01PM +0200, Alexander Gordeev wrote: > > > > Commit 0005d20 ("mm/gup: Move page table entry dereference > > > > into helper function") wrapped access to page table entries > > > > larger than sizeof(long) into a race-aware accessor. One of > > > > the two dereferences in gup_fast path was however overlooked. > > > > > > > > CC: Kirill A. Shutemov > > > > CC: linux-mm@kvack.org > > > > Signed-off-by: Alexander Gordeev > > > > mm/gup.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/mm/gup.c b/mm/gup.c > > > > index d53f7dd..eceb98b 100644 > > > > +++ b/mm/gup.c > > > > @@ -2208,7 +2208,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end, > > > > if (!head) > > > > goto pte_unmap; > > > > > > > > - if (unlikely(pte_val(pte) != pte_val(*ptep))) { > > > > + if (unlikely(pte_val(pte) != pte_val(gup_get_pte(ptep)))) { > > > > > > It doesn't seem like this needs the special helper as it is just > > > checking that the pte hasn't changed, it doesn't need to be read > > > exactly. > > > > > > But it probably should technically still be a READ_ONCE. Although I > > > think the atomic inside try_grab_compound_head prevents any real > > > problems. > > > > I think we should go for consistency here and use the helper function. > > It seems quite expensive to do two more unncessary barriers.. But won't a failure to read the 'real' pte result in falling back to GUP slow? Not sure which is worse? And most arch's don't suffer from this... Ira