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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 378E3C48BF8 for ; Mon, 19 Feb 2024 15:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tCThVwO5XR9o5Y/VYCVnIvxb5g2pUhSn7d25GwGS4mc=; b=BkogGVSUa3KDGB 6uPiaNwtdd4VTBX1Gz4M1G6aQJj5zRh+djn+4ic7x3tlbjuj1QrAafyITb8taVs+rh3ftDa4K3IGt x0d7kfda5aelwWsy599KS3hk1CH0JTYuu+bYN38RXoR1o5Llngb8IQGhes3M3SFksRctjx2zKg+Dz 9WOi7kfoX9SQnVnBDYhdIhb2PXD5F8zQNkxZFYR/Xw6bdtqXrkSrHFbDUEmAf69g3jh4V7tKKzSaS QFFYO2rLw0BVnj+/E8p866SgPgCDFtYPNs5rkOEZYZGVXLtBN/+opqyz/irV4obEkxaNSYPj9bS8m uv/kUk3txIxqLby/W3HA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rc5Pq-0000000B49w-22pE; Mon, 19 Feb 2024 15:18:46 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rc5Po-0000000B48e-02tZ for linux-arm-kernel@lists.infradead.org; Mon, 19 Feb 2024 15:18:45 +0000 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-Disposition: inline In-Reply-To: <892caa6a-e4fe-4009-aa33-0570526961c5@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240219_071844_510527_4E2E5CFB X-CRM114-Status: GOOD ( 31.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel