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=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 8C197C48BE6 for ; Wed, 16 Jun 2021 10:27:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 385A46128B for ; Wed, 16 Jun 2021 10:27:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 385A46128B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CADA16B006E; Wed, 16 Jun 2021 06:27:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C722B6B0070; Wed, 16 Jun 2021 06:27:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3AF96B0071; Wed, 16 Jun 2021 06:27:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 843F56B006E for ; Wed, 16 Jun 2021 06:27:50 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 20D3912F7 for ; Wed, 16 Jun 2021 10:27:50 +0000 (UTC) X-FDA: 78259211100.14.BEB5D08 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf10.hostedemail.com (Postfix) with ESMTP id 650FB4202A14 for ; Wed, 16 Jun 2021 10:27:40 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id ACDD760FE6; Wed, 16 Jun 2021 10:27:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623839268; bh=OntBdQanyH4j4587k9+3vVoVgxxu9A4265Aw3crQwWk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t5MiRgCyT2CgyazEYiT1/RJyRt3uFtZnlTAqXM65t9fftQVapUPYihY8Ia9pq7xaV wWgjTNpNXpgrwvUJnZs0HquC/biLZq0z8eGOtpvODYKhbFKMVVpBl29iKz3zyWOgST vaQ6YQLPeSrlWhBZ/mLtbc/9zmnsVvReGYCv2NfHkNnFMtz51abwgxFyDVd6WVGLAd 4q3sC8QEG1kzpZonXKh6ETuZwtnnK7aq09C2VQelS/QMn3HWADfxI6woWzxt2D9zHQ 4DMd4hKaMMyrXg3xwpR2Eca3xlh3xOwJfmLJ6FAdQC44FOcWVLAyHfqSObsWBGVEPH MBES7ArMpwcgg== Date: Wed, 16 Jun 2021 11:27:43 +0100 From: Will Deacon To: Jason Gunthorpe 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: <20210616102742.GC22350@willie-the-truck> 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> <20210616004207.GU1096940@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210616004207.GU1096940@ziepe.ca> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 650FB4202A14 X-Stat-Signature: a9in7kzpqnsnk8yenwmsfhp3p6t7tj8f Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t5MiRgCy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of will@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=will@kernel.org X-HE-Tag: 1623839260-843783 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 09:42:07PM -0300, Jason Gunthorpe wrote: > 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. Oh, no objection to cleaning this up. It was a "issuing msync(2) causes data loss argh!" issue, so adding READ_ONCE() to all the macros was the most straightforward way to solve the immediate problem. Generally speaking, I think all accesses to live page-tables should be using READ_ONCE(), as there's also hardware updates from the CPU table walker to contend with. If that's done in the caller and the macros are changed to operate on the loaded value, all the better (although this probably doesn't work so well once you get into rmw operations such as ptep_test_and_clear_young()). Will