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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20DD2C48BF8 for ; Mon, 19 Feb 2024 15:18:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A64BC6B0087; Mon, 19 Feb 2024 10:18:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A14D66B0088; Mon, 19 Feb 2024 10:18:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DC7C6B0089; Mon, 19 Feb 2024 10:18:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7E51E6B0087 for ; Mon, 19 Feb 2024 10:18:47 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 15B3E12048A for ; Mon, 19 Feb 2024 15:18:47 +0000 (UTC) X-FDA: 81808910694.22.B3702EB Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf23.hostedemail.com (Postfix) with ESMTP id A30CE140014 for ; Mon, 19 Feb 2024 15:18:44 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708355925; a=rsa-sha256; cv=none; b=lObmgOlTd17+xH+lt0W23SXgTXMCGtYtQeXPilakA2+y6E1HRvsEfUAJe8TOBqbe30n/yY LqeX15nX1Zyq8DPipUy/wwjEVnsbKlmQQeQF+IGIszkxk71T/tH0jiElGoK/djdsBZh42P Rh05v3TkoUmqSafew4ya0gh0Rk5SAgs= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708355925; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Roq0vh187tFs1nNPc72IO5rTUB9JixlfKY0u0BhH5ao=; b=7wHMungbd0H3ZeJd95p84+DiZGW9ioIWc1TRwLNVn/1+g3sBs0fr/ZmdSYo8TaKVxadG0n w3jreCN9/xuuyt3J4gG8A/fYoJ6D4MiTgDwew+b8n5bg4oK1aBlr/207NnldBoj9uIHBV0 zoYqcvx1QTXcSveldk4Q06otz+bkP64= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 51CD9CE127E; Mon, 19 Feb 2024 15:18:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 179F3C433F1; Mon, 19 Feb 2024 15:18:35 +0000 (UTC) Date: Mon, 19 Feb 2024 15:18:33 +0000 From: Catalin Marinas To: Ryan Roberts Cc: Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , Mark Rutland , David Hildenbrand , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings Message-ID: References: <20240215103205.2607016-1-ryan.roberts@arm.com> <20240215103205.2607016-13-ryan.roberts@arm.com> <892caa6a-e4fe-4009-aa33-0570526961c5@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <892caa6a-e4fe-4009-aa33-0570526961c5@arm.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A30CE140014 X-Stat-Signature: 3ejmn84qm9c9crw3x3qax3dxeacu45rq X-HE-Tag: 1708355924-261794 X-HE-Meta: U2FsdGVkX188xIlsQMxsWCel0nRnpBfKfmrkmpGyBMJ0aqgMX65NjywLhd/OXRWjmmFqm8SDkAOQXQIQRXUOCcLQ5Vh1krpr0fZhhEeWEMOi1Co6NUihjcXPT8AT8O7RwcqhRGe+JDxN1hZ+qSA/FfTYNd/4upwXaVg23f905eCIZnaVN4aPIxcf11I2UT8DFlO+l/vt2q4XxinSH/TTKkFfw8DHo2zO9dfqRpuynlmjDn2KTDzMSKcGJVxBsLbUXyiT81b1vYFqOGlof3fLcwXSp9nR1S0Lpxgr727TDUv8VqI89MK4ZO4gWP9NpU0pEQ8hH/o2o5+2HmY4Q0i9REFx2IRSvzlstfRktW4BHxnbNWLBrBQ9gdKcmqpVYU7VR2JS8dfS2+k2bQviqDPmfgaliIOMnCM4LFX0sS60dwig/52fXwHODa3zzKqmv5YLIR6RAj8XwSVt/scJm9lg7QJx8dHBF7yGIjN9yGWlvDuQ9XpVejXmSfXu0W4EX6rpgXRwGEIx203/dpE7B/Z7f69RaRYUX8pqqYntt3IlQ3oKVH6OLnFnZLKKHAZuB9veKsOfJLaVc1lwUbhURFZETACI3S4NH0AwbuuQNYrHLqHV5N+Uka3thHVfce+ysKwiZo7frBr7P8+JfO8Km7FIYCv/H2OF0454znH3Z+iIQmzrFEVK4D0V4iCZg7XPod6uY34pnP4MD7jolnAzvny5Wx/qEndZAAkpIu4dmAB4oz4HLUSCV95JWEGrWZ91g+ahFptQNPqK0ecJXU1EM31blj5Lp6u7W25/0HY+seXU4fBrsFfD0EF6B51ApvZiiwpE8NUQvkKIXwJ2i7MyQP8HfxJ35qFF6nCo3sS9eMtVnCDTmV8sIMa1g+4InD9oZjvT71iePNIjpEIp9bJ3VBDJcVND7Om82tw2F/jVV9/TXJxvJw4al+XhYPZmoST5v9A6DF1otKAp2TR2/cFdOkB jvp8cn1/ JKIKKzRBAKflnkZbLRwDPmGdvdIA1gVbauFs/KBi1Ae70o7AVQtfowv/4Ugh2rRWnqbCxmp1jSoLIBLNd8Nyo7eGy5okHGA+JMcRXF744oS9aJN937Wtd/8c5ggh3GKL+U/NLEmt38KUxKFGGmlgtQp4uLGng69F8gXWsRNLFI4RF/MwcgnfD3ajUWmdWdsmfkorW2qb9OdxhJKrg5xqb8LH0wW/AolJYVWPycs7kzgD2ramT07oBVlVix7IxunM9DEo6gG+Ub52rlgdGC53vASZAHhqgFm6fTWw+u7rCFI5xhRtTkLVvBy9A+iFcA9Asr05ZCx5iNnH1Bi8NPt6OXuVU9e28vWF7NKIpw1UWlWyQM4sJUCwrBFrvDb0UMn3c52jEukI7lqv9e9JVqqGltqT3n5atsG7SnAEczO9706Pjh6VVaRJGWBm+BA== 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: List-Subscribe: List-Unsubscribe: On Fri, Feb 16, 2024 at 12:53:43PM +0000, Ryan Roberts wrote: > On 16/02/2024 12:25, Catalin Marinas wrote: > > On Thu, Feb 15, 2024 at 10:31:59AM +0000, Ryan Roberts wrote: > >> +pte_t contpte_ptep_get_lockless(pte_t *orig_ptep) > >> +{ > >> + /* > >> + * Gather access/dirty bits, which may be populated in any of the ptes > >> + * of the contig range. We may not be holding the PTL, so any contiguous > >> + * range may be unfolded/modified/refolded under our feet. Therefore we > >> + * ensure we read a _consistent_ contpte range by checking that all ptes > >> + * in the range are valid and have CONT_PTE set, that all pfns are > >> + * contiguous and that all pgprots are the same (ignoring access/dirty). > >> + * If we find a pte that is not consistent, then we must be racing with > >> + * an update so start again. If the target pte does not have CONT_PTE > >> + * set then that is considered consistent on its own because it is not > >> + * part of a contpte range. > >> +*/ [...] > > After writing the comments above, I think I figured out that the whole > > point of this loop is to check that the ptes in the contig range are > > still consistent and the only variation allowed is the dirty/young > > state to be passed to the orig_pte returned. The original pte may have > > been updated by the time this loop finishes but I don't think it > > matters, it wouldn't be any different than reading a single pte and > > returning it while it is being updated. > > Correct. The pte can be updated at any time, before after or during the reads. > That was always the case. But now we have to cope with a whole contpte block > being repainted while we are reading it. So we are just checking to make sure > that all the ptes that we read from the contpte block are consistent with > eachother and therefore we can trust that the access/dirty bits we gathered are > consistent. I've been thinking a bit more about this - do any of the callers of ptep_get_lockless() check the dirty/access bits? The only one that seems to care is ptdump but in that case I'd rather see the raw bits for debugging rather than propagating the dirty/access bits to the rest in the contig range. So with some clearer documentation on the requirements, I think we don't need an arm64-specific ptep_get_lockless() (unless I missed something). -- Catalin