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.8 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 416E4C48BE5 for ; Wed, 16 Jun 2021 00:42:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FE8161107 for ; Wed, 16 Jun 2021 00:42:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FE8161107 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 0FD9D6B0070; Tue, 15 Jun 2021 20:42:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D4416B0071; Tue, 15 Jun 2021 20:42:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB6E06B0072; Tue, 15 Jun 2021 20:42:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id BB0136B0070 for ; Tue, 15 Jun 2021 20:42:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 55C4E180AD804 for ; Wed, 16 Jun 2021 00:42:09 +0000 (UTC) X-FDA: 78257735178.14.37264A2 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf30.hostedemail.com (Postfix) with ESMTP id 8892AE000255 for ; Wed, 16 Jun 2021 00:42:02 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id w4so696283qvr.11 for ; Tue, 15 Jun 2021 17:42:08 -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=MIZ4yfC4SJgSNnStHS2hV3bUSJEXPyXqzvDWBqSA7IE=; b=cWN9BUfrVnGFbKtIZ3DUiBrsX0OUV8SZhasHlYTeBCPpr+9HP+e1oLZNvWMtAC6mf1 4kaEpIOLkAi6/aS52oOQPP4kOSQoqo0hJCMz+o7bSU8h2xRKXHhdtK4Zk2AxgMhq5c8K eWEdVeBmPJ8BM4s2GRBLWOufFUci7yk25ulljFjU1IZGfSsFyPBhC7Bsyhih+GSkT8f9 7IpF1EisdHdnKvhp96F5VwcH4jVLVZU8gqwU7I9wGhymUikzXA0ZXRhwrZKcsFxEwc48 AHDTzbf217WABi3UZZY6k8XHo2PdNQofBpiUSv0wy2sia396vWRsy15ft0KLorI4wB4x V5MQ== 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=MIZ4yfC4SJgSNnStHS2hV3bUSJEXPyXqzvDWBqSA7IE=; b=e/kKkpgEW6m605YUxlazFm/tEaBW4HDPFuYVeC6+W2XCyt37em11TiJm4aBG9x28np U1FblKyDtcIqon14xn2GD+enrDkUIetDzHHY9wde1xrBYNSr+gD2am6NIeM75Cea8UYf l5hONGc3oH5Qyc1Uy9Du2yfDqaWQoFsj60BzAXDM30ndyFVwlZUJhORqhbTrwu4CLJyi HiFRxz7myiUF6x4vzkPIktZEBwvHMPooOaggRTJZHQFhnQS9HUndNln871cAU424LMfB /tUVDtKJ3Ip4wckgJUDHkJZwwjU8k2ra+jxSePsv0Noil4F1mmYMHI17gnF3STVrfvpI y/FA== X-Gm-Message-State: AOAM531nLv1mIsONUwb0YpOA7vC7HyR7gHcvI2e93FHg6OWE+ltXJo7T 6q2mK1gaMPxG5AVq7supVUnxHA== X-Google-Smtp-Source: ABdhPJzCCGXNtFKeBaAZBtslYwxAwLPkiq4om2TrlrIrdMkTrd8Mjvp7+4aeQphN8xrVeKEzLcOXGg== X-Received: by 2002:a05:6214:7f1:: with SMTP id bp17mr8079423qvb.29.1623804128267; Tue, 15 Jun 2021 17:42:08 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-47-55-113-94.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.113.94]) by smtp.gmail.com with ESMTPSA id s23sm95645qtq.2.2021.06.15.17.42.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jun 2021 17:42:07 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1ltJd9-007I9Y-2M; Tue, 15 Jun 2021 21:42:07 -0300 Date: Tue, 15 Jun 2021 21:42:07 -0300 From: Jason Gunthorpe To: Will Deacon Cc: Hugh Dickins , "Kirill A. Shutemov" , Andrew Morton , "Kirill A. Shutemov" , Yang Shi , Wang Yugui , Matthew Wilcox , Alistair Popple , Ralph Campbell , Zi Yan , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/11] mm: page_vma_mapped_walk(): use pmd_read_atomic() Message-ID: <20210616004207.GU1096940@ziepe.ca> References: <589b358c-febc-c88e-d4c2-7834b37fa7bf@google.com> <594c1f0-d396-5346-1f36-606872cddb18@google.com> <20210610090617.e6qutzzj3jxcseyi@box.shutemov.name> <20210610121542.GQ1096940@ziepe.ca> <20210611153613.GR1096940@ziepe.ca> <939a0fa-7d6c-f535-7c34-4c522903e6f@google.com> <20210611194249.GS1096940@ziepe.ca> <20210615094639.GC19878@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210615094639.GC19878@willie-the-truck> Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=cWN9BUfr; spf=pass (imf30.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.46 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8892AE000255 X-Stat-Signature: soyaa1zwywcexr5dwhdpw8hhkzkm6tfp X-HE-Tag: 1623804122-693052 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, Jun 15, 2021 at 10:46:39AM +0100, Will Deacon wrote: > Then the compiler can allocate the same register for x and z, but will > issue an additional load for y. If a concurrent update takes place to the > pmd which transitions from Invalid -> Valid, then it will look as though > things went back in time, because z will be stale. We actually hit this > on arm64 in practice [1]. The fact you actually hit this in the real world just seem to confirm my thinking that the mm's lax use of the memory model is something that deserves addressing. Honestly I'm not sure the fix to stick a READ_ONCE in the macros is very robust. I prefer the gup_fast pattern of: pmd_t pmd = READ_ONCE(*pmdp); pte_offset_phys(&pmd, addr); To correctly force the READ_ONCE under unlocked access and the consistently use the single read of the unstable data. It seems more maintainable 'hey look at me, I have no locks!' and has fewer possibilities for obscure order related bugs to creep in. Jason