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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 03214108B8EA for ; Fri, 20 Mar 2026 09:57:53 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4fcdKX3d2yz2yYY; Fri, 20 Mar 2026 20:57:52 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=172.105.4.254 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1774000672; cv=none; b=KvLH5QM4e2LGuiUkXCrrE/rEFabvWXLXWHo0HEymabDh2fnJIFwXxZINGwOTqLk5bRyjoJaIaaehXiR7C6ZSqpOhkckMM+0Vs8RHpbk28YXhzXci6i7TYAjI87es4aYQKKootYmmgGp+v2mTDTUQiFfpP+xvge2Mx/8L0RK07VhI4GgurWY+AAA7S3Lxh3Lk9Qjs64NQlB/R2qSHJiW+Q9p154a6leYF9/7PXx/atBwcYziXk0MwB4aIIYsJgmCgft0fQ9yiD71OtrDElTeROyVwANwo9SzpFowJi8CoFwB9FFKdbCAg52gtoq4pictFnafo9i1Exj/Zv8qq6zcy1Q== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1774000672; c=relaxed/relaxed; bh=wZhQy9sYfs9QbFM4ofQ8Qic3K9F6jlM21wqnv9KjgSM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FlJJ1iHZpMVb5QBb353dAEQa0lF+2Z2RiUD/jnz9rwrRDFWHZmwySbbLisCupPvMku967v43zFwvS5GYeDVnnWyknAs6alxmpbaP1E7bgUlN6Cl54wYGHas6CAI/E70zr1Ql2hr5ly0HC7hCedenoYbxzwe3CPNrO0no1Oi1b8BhMoGg4o4QekUFYURxFId6O64TnE3hbMmfIEqSQhMjYdm7PWGBRq0Xzhm0hlPVIXSuTAITMhn7UdrxzBTgMyzominv9K1pkAhji4k7F2g5NZSwwJ3q0V+olAYd6f70hoh7FTYACTeXoMb5VUqe1JtuL6MIgl/LoqlOa9uCDjFkUw== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=QQRWsGQH; dkim-atps=neutral; spf=pass (client-ip=172.105.4.254; helo=tor.source.kernel.org; envelope-from=vbabka@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=QQRWsGQH; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=172.105.4.254; helo=tor.source.kernel.org; envelope-from=vbabka@kernel.org; receiver=lists.ozlabs.org) Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4fcdKW3Kmnz2yY1 for ; Fri, 20 Mar 2026 20:57:51 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 840DC60127; Fri, 20 Mar 2026 09:57:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 857BBC4CEF7; Fri, 20 Mar 2026 09:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774000668; bh=BHH+c4Y1mXQAFcGaqGCCWfuTYkgGp//q1BrbsXIDSaQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=QQRWsGQH7qeVicMQ3QSUVrL6+6ykgppWH2udWWMxJcvzUOilTI2D7Y834vvr9Cqyt icef8KeIyRBqnM8w4ArrDNWl6Ob6UJXBNgrvlMt/tBdIreYgyDBKMJlUoyuOasLmfa iMtWGY20neqLWTJ9QFVatHUq5kcOHBKCnWsq8XUDgm0NFAhoArRULvDwYK/kV6czLG 7ILzyx2cbMCcr+fQ27sX6WdG5X0iCQZVcM/UkIyri/M4ayLGpsmDafgz5CXXcO9/eT NoXV7TLdZ3AryMYN76uq3e720RaA8DpDZue8f2q9/TUxNy/PRtDVcIeYSQDOm+3jmm Zksp5/xFc4XNg== Message-ID: <1d300b3b-2476-4381-b8df-a680f486b284@kernel.org> Date: Fri, 20 Mar 2026 10:57:32 +0100 X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 17/23] mm: convert do_brk_flags() to use vma_flags_t Content-Language: en-US To: "Lorenzo Stoakes (Oracle)" , Andrew Morton Cc: David Hildenbrand , "Liam R . Howlett" , Jann Horn , Pedro Falcato , Mike Rapoport , Suren Baghdasaryan , Kees Cook , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Brian Cain , Huacai Chen , WANG Xuerui , Thomas Bogendoerfer , Dinh Nguyen , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Richard Weinberger , Anton Ivanov , Johannes Berg , Alexander Viro , Christian Brauner , Jan Kara , Xu Xin , Chengming Zhou , Michal Hocko , Paul Moore , Stephen Smalley , Ondrej Mosnacek , linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-um@lists.infradead.org, linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org References: <981ed1afcd19115432e61778e7d226a36f8f5c2b.1773846935.git.ljs@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: <981ed1afcd19115432e61778e7d226a36f8f5c2b.1773846935.git.ljs@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/18/26 16:50, Lorenzo Stoakes (Oracle) wrote: > In order to be able to do this, we need to change VM_DATA_DEFAULT_FLAGS > and friends and update the architecture-specific definitions also. > > We then have to update some KSM logic to handle VMA flags, and introduce > VMA_STACK_FLAGS to define the vma_flags_t equivalent of VM_STACK_FLAGS. > > We also introduce two helper functions for use during the time we are > converting legacy flags to vma_flags_t values - vma_flags_to_legacy() and > legacy_to_vma_flags(). Nit: this was done by an earlier patch. > This enables us to iteratively make changes to break these changes up into > separate parts. > > We use these explicitly here to keep VM_STACK_FLAGS around for certain > users which need to maintain the legacy vm_flags_t values for the time > being. > > We are no longer able to rely on the simple VM_xxx being set to zero if > the feature is not enabled, so in the case of VM_DROPPABLE we introduce > VMA_DROPPABLE as the vma_flags_t equivalent, which is set to > EMPTY_VMA_FLAGS if the droppable flag is not available. > > While we're here, we make the description of do_brk_flags() into a kdoc > comment, as it almost was already. > > We use vma_flags_to_legacy() to not need to update the vm_get_page_prot() > logic as this time. > > Note that in create_init_stack_vma() we have to replace the BUILD_BUG_ON() > with a VM_WARN_ON_ONCE() as the tested values are no longer build time > available. > > We also update mprotect_fixup() to use VMA flags where possible, though we > have to live with a little duplication between vm_flags_t and vma_flags_t > values for the time being until further conversions are made. > > Finally, we update the VMA tests to reflect these changes. > > Acked-by: Paul Moore [SELinux] > Signed-off-by: Lorenzo Stoakes (Oracle) Acked-by: Vlastimil Babka (SUSE) More nits below: > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h > index b39cc1127e1f..e25d0d18f6d7 100644 > --- a/arch/arm64/include/asm/page.h > +++ b/arch/arm64/include/asm/page.h > @@ -46,7 +46,12 @@ int pfn_is_map_memory(unsigned long pfn); > > #endif /* !__ASSEMBLER__ */ > > -#define VM_DATA_DEFAULT_FLAGS (VM_DATA_FLAGS_TSK_EXEC | VM_MTE_ALLOWED) > +#ifdef CONFIG_ARM64_MTE > +#define VMA_DATA_DEFAULT_FLAGS append_vma_flags(VMA_DATA_FLAGS_TSK_EXEC, \ > + VMA_MTE_ALLOWED_BIT) I wonder what's the bloat-o-meter impact of these #define's (this arm64-specific one isn't the only one) being no longer compile-time-constants? > +#else > +#define VMA_DATA_DEFAULT_FLAGS VMA_DATA_FLAGS_TSK_EXEC > +#endif > > #include > > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > > +#define VMA_STACK_FLAGS append_vma_flags(VMA_STACK_DEFAULT_FLAGS, \ > + VMA_STACK_BIT, VMA_ACCOUNT_BIT) > + > +/* Temporary until VMA flags conversion complete. */ > +#define VM_STACK_FLAGS vma_flags_to_legacy(VMA_STACK_FLAGS) > + > #define VM_STARTGAP_FLAGS (VM_GROWSDOWN | VM_SHADOW_STACK) > > #ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS > @@ -536,8 +547,6 @@ enum { > #define VM_SEALED_SYSMAP VM_NONE > #endif > > -#define VM_STACK_FLAGS (VM_STACK | VM_STACK_DEFAULT_FLAGS | VM_ACCOUNT) > - > /* VMA basic access permission flags */ > #define VM_ACCESS_FLAGS (VM_READ | VM_WRITE | VM_EXEC) > #define VMA_ACCESS_FLAGS mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT) > @@ -547,6 +556,9 @@ enum { > */ > #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP) > > +#define VMA_SPECIAL_FLAGS mk_vma_flags(VMA_IO_BIT, VMA_DONTEXPAND_BIT, \ > + VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT) Should VM_SPECIAL be also redefined using vma_flags_to_legacy()? > + > /* > * Physically remapped pages are special. Tell the > * rest of the world about it: > @@ -1412,7 +1424,7 @@ static __always_inline void vma_desc_set_flags_mask(struct vm_area_desc *desc, > * vm_area_desc object describing a proposed VMA, e.g.: > * > * vma_desc_set_flags(desc, VMA_IO_BIT, VMA_PFNMAP_BIT, VMA_DONTEXPAND_BIT, > - * VMA_DONTDUMP_BIT); > + * VMA_DONTDUMP_BIT); Looks like spurious tabs-to-space change inconsistent with other instances. > */ > #define vma_desc_set_flags(desc, ...) \ > vma_desc_set_flags_mask(desc, mk_vma_flags(__VA_ARGS__)) > @@ -4059,7 +4071,6 @@ extern int replace_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file); > extern struct file *get_mm_exe_file(struct mm_struct *mm); > extern struct file *get_task_exe_file(struct task_struct *task); > > -extern bool may_expand_vm(struct mm_struct *, vm_flags_t, unsigned long npages); > extern void vm_stat_account(struct mm_struct *, vm_flags_t, long npages); > > extern bool vma_is_special_mapping(const struct vm_area_struct *vma, > diff --git a/mm/internal.h b/mm/internal.h > index f98f4746ac41..80d8651441a7 100644 > diff --git a/mm/mprotect.c b/mm/mprotect.c > index 9681f055b9fc..eaa724b99908 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -773,19 +778,24 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb, > > change_protection(tlb, vma, start, end, mm_cp_flags); > > - if ((oldflags & VM_ACCOUNT) && !(newflags & VM_ACCOUNT)) > + if (vma_flags_test(&old_vma_flags, VMA_ACCOUNT_BIT) && > + !vma_flags_test(&new_vma_flags, VMA_ACCOUNT_BIT)) > vm_unacct_memory(nrpages); > > /* > * Private VM_LOCKED VMA becoming writable: trigger COW to avoid major > * fault on access. > */ > - if ((oldflags & (VM_WRITE | VM_SHARED | VM_LOCKED)) == VM_LOCKED && > - (newflags & VM_WRITE)) { > - populate_vma_page_range(vma, start, end, NULL); > + if (vma_flags_test(&new_vma_flags, VMA_WRITE_BIT)) { > + const vma_flags_t mask = > + vma_flags_and(&old_vma_flags, VMA_WRITE_BIT, > + VMA_SHARED_BIT, VMA_LOCKED_BIT); > + > + if (vma_flags_same(&mask, VMA_LOCKED_BIT)) That converts the original logic 1:1, but I wonder if it's now feasible to write it more obviously as "VMA_LOCKED_BIT must be set, VM_WRITE_BIT and VM_SHARED_BIT must not" ? > + populate_vma_page_range(vma, start, end, NULL); > } > > - vm_stat_account(mm, oldflags, -nrpages); > + vm_stat_account(mm, vma_flags_to_legacy(old_vma_flags), -nrpages); > vm_stat_account(mm, newflags, nrpages); > perf_event_mmap(vma); > return 0; > diff --git a/mm/vma.h b/mm/vma.h > index cf8926558bf6..1f2de6cb3b97 100644 > --- a/mm/vma.h > +++ b/mm/vma.h > +static inline bool is_data_mapping_vma_flags(const vma_flags_t *vma_flags) > +{ > + const vma_flags_t mask = vma_flags_and(vma_flags, > + VMA_WRITE_BIT, VMA_SHARED_BIT, VMA_STACK_BIT); > + > + return vma_flags_same(&mask, VMA_WRITE_BIT); Ditto? > +} > > static inline void vma_iter_config(struct vma_iterator *vmi, > unsigned long index, unsigned long last) > diff --git a/mm/vma_exec.c b/mm/vma_exec.c > index 8134e1afca68..5cee8b7efa0f 100644