From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD7A33537D5 for ; Thu, 9 Apr 2026 10:38:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775731082; cv=none; b=erVA2zpqwKDRorvzSI7Pa37dQg9wG4qH8ZJYi1YAqpwZSqPFaV5bvEglnJaIw7l5MJr9T3FnkQ7f9WQUCrGXhzhccdQyCJfOnUguIuD1NTZINV+UXDBnl/72TlCbZT3BdSJ56A2KhmHgxb56ohKcPAujSM+I0hHtcX3XHaV+J80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775731082; c=relaxed/simple; bh=976DNqeQEs7Pl86bSQIumgGXPxpOrVddLnDDmQWOHVQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GcDSl4MzP/p2/NPE55eDFcM+2JMZpfEw/ayOO/BDVBehcO9O8ks26i6dSCbABH9o2ZEBvWgGsNUcZYg6/Q/4YSfj4rDqKysD85aO28u7z/2sxm3PwNZGme2tIvPQX0Pby01aDVlqeEOL8jf+RIp4h0Ogph6QmZe2tvVsIrbpPus= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QmNCOPRP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QmNCOPRP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93843C4CEF7; Thu, 9 Apr 2026 10:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775731082; bh=976DNqeQEs7Pl86bSQIumgGXPxpOrVddLnDDmQWOHVQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QmNCOPRP43UhzksR5XQpFQQoocT2bmpB7xLiO8PisbEJ+AXcLEkykvdo55fWP3r+n dsZssJP/kYRRyzIhHvcVafJaWpGsgo9h6GFwGgr0oap6IlXPbfNbqvQKIVIUpBTqb5 VwxcYF9KUnhIpRqTf8ZO5MIu/NxSPZFVMadq5ELnHLLcGRsGat01tlsqwV1uAtGoPo n5vPo1Pv0g/MOsD/d/7Qb9RIXa8H6jK+kD5jSd+ijK3Mgts74y6z8x42c/muXrOQjL p8BOJGYMNnkMiTzYr2CH2yTi2aHvRDh+mYu2d4n4BEYrwgD8AjaOqiVPeKDrRLEhYO VSf+/+rUX3yfQ== Date: Thu, 9 Apr 2026 13:37:55 +0300 From: Mike Rapoport To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Ryan Roberts , Mark Rutland , Lorenzo Stoakes , Andrew Morton , David Hildenbrand , Linu Cherian , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC V1 02/16] mm: Add read-write accessors for vm_page_prot Message-ID: References: <20260224051153.3150613-1-anshuman.khandual@arm.com> <20260224051153.3150613-3-anshuman.khandual@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260224051153.3150613-3-anshuman.khandual@arm.com> Hi Anshuman, On Tue, Feb 24, 2026 at 10:41:39AM +0530, Anshuman Khandual wrote: > Currently vma->vm_page_prot is safely read from and written to, without any > locks with READ_ONCE() and WRITE_ONCE(). But with introduction of D128 page > tables on arm64 platform, vm_page_prot grows to 128 bits which can't safely > be handled with READ_ONCE() and WRITE_ONCE(). > > Add read and write accessors for vm_page_prot like pgprot_read/write_once() > which any platform can override when required, although still defaulting as > READ_ONCE() and WRITE_ONCE(), thus preserving the functionality for others. > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Lorenzo Stoakes > Cc: Mike Rapoport > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual > --- > include/linux/pgtable.h | 14 ++++++++++++++ > mm/huge_memory.c | 4 ++-- > mm/memory.c | 2 +- > mm/migrate.c | 2 +- > mm/mmap.c | 2 +- > 5 files changed, 19 insertions(+), 5 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index da17139a1279..8858b8b03a02 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -495,6 +495,20 @@ static inline pgd_t pgdp_get(pgd_t *pgdp) > } > #endif > > +#ifndef pgprot_read_once > +static inline pgprot_t pgprot_read_once(pgprot_t *prot) I don't think we need _once in the helper name. Presence of the helper already implies that pointer should not be just dereferenced from one side and that using the helper will do The Right Thing from the other side. -- Sincerely yours, Mike.