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 283AF264638; Thu, 19 Jun 2025 08:42:29 +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=1750322550; cv=none; b=ePqdSfPbKxbkbfnbHyqPHNmsWOWDfNcdFhg0Jni8YphW7G/dAc9beyC22bzOtB9WMgNBINLUpPig5UDetY8SDq6cjHr5uvaMcUAG8WHGgOPVs5cNwBiWx+oV//ryl60MCWgAv+APSAfqVaFF5rlkooUQb1lih+U+5Ik+ZX3T9Ko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750322550; c=relaxed/simple; bh=3VFuG2FOQta3qfo/tXfeyceWpM2CtNcoqXoxG/UtwWc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FYDCydWsCcZHM6bs4ztQXS+x2V51A3WCpfWBlYG0V10ELhXoTBg+0wIxRIPdcpHJbuWvxrqU6yJaTHIZlmxlElm9x5LncCt8fmy/Uv2IX6kEHPcUgpr8HvAsJHkJp1eS4FKJdWaLYcrajTgCf7UUZC+4wzUoE6AtnMhcs7HcXmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SErdEUma; 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="SErdEUma" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04FBBC4CEEA; Thu, 19 Jun 2025 08:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750322549; bh=3VFuG2FOQta3qfo/tXfeyceWpM2CtNcoqXoxG/UtwWc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SErdEUmaRiXUtAdabhdTNYYV8q5kEViKHeMvbdP07i8SdJqnyGDweje7/hf5ob2r1 Y7GakfurOZd/kO55Uuejfbjb1S87B2AsLMEOZS16N3PqMiLkRzq0uK6SYLU7qgvTU/ SVw+UbeIJFOnBUY3xSh5j8mzLsb/i9WbBp9W6Nyzn5AswOiCpHExDyjKEa4xghVxhq qVMVSR8Ah8c9+Gp0UD1wpCI2KA3aEvgMXWU2aB9vqWItkHQLyOH3Ng4vCX7N4MSO38 GNkOCm/RoBAbDnsH25JuklGSA+93rTqS16MvDDHIq0NGhvg1unBUyT6Up6WtuKaRQA 0XljRO/7NmUxw== Date: Thu, 19 Jun 2025 10:42:14 +0200 From: Christian Brauner To: Lorenzo Stoakes Cc: Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "David S . Miller" , Andreas Larsson , Jarkko Sakkinen , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Alexander Viro , Jan Kara , Kees Cook , Peter Xu , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Xu Xin , Chengming Zhou , Hugh Dickins , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Rik van Riel , Harry Yoo , Dan Williams , Matthew Wilcox , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jason Gunthorpe , John Hubbard , Muchun Song , Oscar Salvador , Jann Horn , Pedro Falcato , Johannes Weiner , Qi Zheng , Shakeel Butt , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, sparclinux@vger.kernel.org, linux-sgx@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, nvdimm@lists.linux.dev, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] mm: change vm_get_page_prot() to accept vm_flags_t argument Message-ID: <20250619-unwiederholbar-addition-6875c99fe08d@brauner> References: Precedence: bulk X-Mailing-List: sparclinux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Wed, Jun 18, 2025 at 08:42:52PM +0100, Lorenzo Stoakes wrote: > We abstract the type of the VMA flags to vm_flags_t, however in may places > it is simply assumed this is unsigned long, which is simply incorrect. > > At the moment this is simply an incongruity, however in future we plan to > change this type and therefore this change is a critical requirement for > doing so. > > Overall, this patch does not introduce any functional change. > > Signed-off-by: Lorenzo Stoakes > --- > arch/arm64/mm/mmap.c | 2 +- > arch/powerpc/include/asm/book3s/64/pkeys.h | 3 ++- > arch/sparc/mm/init_64.c | 2 +- > arch/x86/mm/pgprot.c | 2 +- > include/linux/mm.h | 4 ++-- > include/linux/pgtable.h | 2 +- > tools/testing/vma/vma_internal.h | 2 +- > 7 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > index c86c348857c4..08ee177432c2 100644 > --- a/arch/arm64/mm/mmap.c > +++ b/arch/arm64/mm/mmap.c > @@ -81,7 +81,7 @@ static int __init adjust_protection_map(void) > } > arch_initcall(adjust_protection_map); > > -pgprot_t vm_get_page_prot(unsigned long vm_flags) > +pgprot_t vm_get_page_prot(vm_flags_t vm_flags) > { > ptdesc_t prot; > > diff --git a/arch/powerpc/include/asm/book3s/64/pkeys.h b/arch/powerpc/include/asm/book3s/64/pkeys.h > index 5b178139f3c0..6f2075636591 100644 > --- a/arch/powerpc/include/asm/book3s/64/pkeys.h > +++ b/arch/powerpc/include/asm/book3s/64/pkeys.h > @@ -4,8 +4,9 @@ > #define _ASM_POWERPC_BOOK3S_64_PKEYS_H > > #include > +#include > > -static inline u64 vmflag_to_pte_pkey_bits(u64 vm_flags) > +static inline u64 vmflag_to_pte_pkey_bits(vm_flags_t vm_flags) If you change vm_flags_t to u64 you probably want to compile with some of these integer truncation options when you're doing the conversion. Because otherwise you risk silently truncating the upper 32bits when assigning to a 32bit variable. We've had had a patch series that almost introduced a very subtle bug when it tried to add the first flag outside the 32bit range in the lookup code a while ago. That series never made it but it just popped back into my head when I read your series. Acked-by: Christian Brauner