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 D8135C48260 for ; Tue, 13 Feb 2024 16:53:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6988F8D0015; Tue, 13 Feb 2024 11:53:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6450F8D000E; Tue, 13 Feb 2024 11:53:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E4FD8D0015; Tue, 13 Feb 2024 11:53:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3B9D88D000E for ; Tue, 13 Feb 2024 11:53:10 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 04B11140922 for ; Tue, 13 Feb 2024 16:53:09 +0000 (UTC) X-FDA: 81787375740.25.45C394F Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 557741A0019 for ; Tue, 13 Feb 2024 16:53:08 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707843188; 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=i/VInZj8WfMRcG9hK9CDrFcZl+U4X7AwgnIibvGE3cQ=; b=t51nLD6uVwNYEpaP/jE7I+nI4J4VTGDkZBwld6iM7DuCJ2RX+zPjigkUqCVTCzFsYHdRFl G+R/8uallqIErrIWXaoNYrQJkC6x/Jbk6j6v8+mFpjW7fYKmqTD2zOENsF8r8iXOqg7doA fOrwx5svE78c+FfFkgGWSPX3VSWnq7M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707843188; a=rsa-sha256; cv=none; b=L8Li0KrT5ae0I3xOEVueuNXA89Bk8g++hvlVXsFHNHAg6k4wTSiM6W0InZfaU2hNp0gV81 GAnpghrs5q18+aTjTcKmCTJlVo43AXZhTZ89uhc43oPl5XiZkMcu0CAdVcumEacmVLoZQf 8AhNNsGKM6SU/i/L5BVGKik2S/iZrxg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CCA9CDA7; Tue, 13 Feb 2024 08:53:48 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.130]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CB5073F5A1; Tue, 13 Feb 2024 08:53:03 -0800 (PST) Date: Tue, 13 Feb 2024 16:53:01 +0000 From: Mark Rutland To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , David Hildenbrand , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , 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 v5 21/25] arm64/mm: Implement new [get_and_]clear_full_ptes() batch APIs Message-ID: References: <20240202080756.1453939-1-ryan.roberts@arm.com> <20240202080756.1453939-22-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 557741A0019 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: prwfysautp1quzx7hgz4kqfsahcbth9h X-HE-Tag: 1707843188-720918 X-HE-Meta: U2FsdGVkX1+SIQRtCk2/I5Gkd7jXTB3EoOQUefQVUrKaVOdEkZnQJZXzJAWXOm3Qn08/nTcqcD5o/PKeeBLgX+Yb9aY1VR/8Z0xBx4UWP+XDNglFmeitn6E5urKOapfZuLgKez9I7T9XB+ak/KfrsebdojNswi1HzL3JQ/jXF1uU3cYF0bySuqenJ4J8kpsMcE+kjzsO9MWX3zaGel2BPRZsELbDT88AMnHNt79H+tOwT1xUWoSlUL4xQDCPejG+t4Ngdzt+9Ia2NBgkOpWxGZ7lSp+UsM4hxRAROt/fGI7vERwPSRXvqRYLbckjo1m7YoHyuESc2eF66PhuSwXX971Bd5MSMwW54sdiRj7MgQrMfLC7sSeunop+hUwgborzOyZCO6jMhGDTqJd2Ccue2jXST4zt6jWP3n/FVK5B4rTWHKI1PMLFylyYb2dJq+MFn+7rUxdpo5HxukqSgrm0FTqFzEAwB6Pj/sFXYs6ynBNO+G2IWE4XM/X8KcRx7pCyUByVaSaJEfBALRNr3PAudcO+8Lv7F4U8vb0MSHjk2Cri7mjB6FgRi31XJ/UmrnBoobxSaPZul5Qj8dDwGVckq40kIfZBWGUt6kIfTXlec5xTwF88cC2+5SoiojjUEU1F+lGsmuBIyvL0G8y4yHCTPuCJ8z0g74aigAH9elxX5Ht8JQIeSadyX1+Mv80xGJ349DCYm2Pf/f1tE/s90vI/+MtcYSPYAkmnEWXRI6O3oWQoh7gsxHtfR66HHBQzPsr8J1TnsDAfVPpryobf+nc+GXZF8cEcMegxKz0/Ys1epX2uqIpf+WP5CjOCFiGlrCUzL128SzBG1nnoST13GNzb4zN6RFfTJpr9RL+CIiijh9YI7OgCW6zgzD+71FsuMoxvJzBdSn7aKJcj1rnR9bB9AexFNXeTUbze5KycZAF8sipf1SLs1yFqZvFkSQiJGwJk6dvkAC8Ttkqgg+fwhye fNPNr9E8 gQBoOmioWFCCfFFAd9bqnP0fTNnvUcrRJUjLMKKfZow1sjAvmdk5fhV/S7ERPHZMJG5l4rP19VQUrpWlKgx5gQSsjJGtjRZMEqOOYL6quJAwwfvo9tSOQnjAsawmSuLSQnhTeGrUNxrHWYC3l5VHkFP3gZs1I9kbpkXOrIrr6wCeVmuuJi4T8/TIj/+33AlwsROhXjJcqHFRTAsRK95lOVml375HnWe4bbhcF3Vbtgzbf1clcElAZDNjs2M9Y2y21nR4RukKpapy714opoMGDAkhYWDLU2K0vWjX0yjD2uuUK/ZUuzKWPq3Q77tnY5AzKPemx 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 Tue, Feb 13, 2024 at 04:48:50PM +0000, Ryan Roberts wrote: > On 13/02/2024 16:43, Mark Rutland wrote: > > On Fri, Feb 02, 2024 at 08:07:52AM +0000, Ryan Roberts wrote: > >> +static inline void __clear_full_ptes(struct mm_struct *mm, unsigned long addr, > >> + pte_t *ptep, unsigned int nr, int full) > >> +{ > >> + for (;;) { > >> + __ptep_get_and_clear(mm, addr, ptep); > >> + if (--nr == 0) > >> + break; > >> + ptep++; > >> + addr += PAGE_SIZE; > >> + } > >> +} > > > > The loop construct is a bit odd; can't this be: > > I found it a little odd at first, but its avoiding the ptep and addr increments > the last time through the loop. Its the preferred pattern for these functions in > core-mm. See default set_ptes(), wrprotect_ptes(), clear_full_ptes() in > include/linux/pgtable.h. > > So I'd prefer to leave it as is so that we match them. What do you think? That's fair enough; it I'm happy with it as-is. Mark.