Message-ID: <brej2b4dxfyuxojzgu2ge7ybk65t234bjstfzfo63izf2woagm@dd5vwcr3d3dg>
Date: Tue, 25 Nov 2025 11:35:23 +0000
From: Pedro Falcato <pfalcato@...e.de>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Muchun Song <muchun.song@...ux.dev>, Oscar Salvador <osalvador@...e.de>, 
	David Hildenbrand <david@...hat.com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, 
	Axel Rasmussen <axelrasmussen@...gle.com>, Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>, 
	Peter Xu <peterx@...hat.com>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>, 
	Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, 
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, 
	Valentin Schneider <vschneid@...hat.com>, Kees Cook <kees@...nel.org>, 
	Matthew Wilcox <willy@...radead.org>, Jason Gunthorpe <jgg@...pe.ca>, 
	John Hubbard <jhubbard@...dia.com>, Leon Romanovsky <leon@...nel.org>, Zi Yan <ziy@...dia.com>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, Nico Pache <npache@...hat.com>, 
	Ryan Roberts <ryan.roberts@....com>, Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>, 
	Lance Yang <lance.yang@...ux.dev>, Xu Xin <xu.xin16@....com.cn>, 
	Chengming Zhou <chengming.zhou@...ux.dev>, Jann Horn <jannh@...gle.com>, 
	Matthew Brost <matthew.brost@...el.com>, Joshua Hahn <joshua.hahnjy@...il.com>, 
	Rakie Kim <rakie.kim@...com>, Byungchul Park <byungchul@...com>, 
	Gregory Price <gourry@...rry.net>, Ying Huang <ying.huang@...ux.alibaba.com>, 
	Alistair Popple <apopple@...dia.com>, Shakeel Butt <shakeel.butt@...ux.dev>, 
	David Rientjes <rientjes@...gle.com>, Rik van Riel <riel@...riel.com>, 
	Harry Yoo <harry.yoo@...cle.com>, Kemeng Shi <shikemeng@...weicloud.com>, 
	Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>, Baoquan He <bhe@...hat.com>, 
	Chris Li <chrisl@...nel.org>, Johannes Weiner <hannes@...xchg.org>, 
	Qi Zheng <zhengqi.arch@...edance.com>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-mm@...ck.org, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Bjorn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, 
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3 4/4] mm: introduce VMA flags bitmap type

On Tue, Nov 25, 2025 at 10:01:02AM +0000, Lorenzo Stoakes wrote:
> It is useful to transition to using a bitmap for VMA flags so we can avoid
> running out of flags, especially for 32-bit kernels which are constrained
> to 32 flags, necessitating some features to be limited to 64-bit kernels
> only.
> 
> By doing so, we remove any constraint on the number of VMA flags moving
> forwards no matter the platform and can decide in future to extend beyond
> 64 if required.
> 
> We start by declaring an opaque types, vma_flags_t (which resembles
> mm_struct flags of type mm_flags_t), setting it to precisely the same size
> as vm_flags_t, and place it in union with vm_flags in the VMA declaration.
> 
> We additionally update struct vm_area_desc equivalently placing the new
> opaque type in union with vm_flags.
> 
> This change therefore does not impact the size of struct vm_area_struct or
> struct vm_area_desc.
> 
> In order for the change to be iterative and to avoid impacting performance,
> we designate VM_xxx declared bitmap flag values as those which must exist
> in the first system word of the VMA flags bitmap.
> 
> We therefore declare vma_flags_clear_all(), vma_flags_overwrite_word(),
> vma_flags_overwrite_word(), vma_flags_overwrite_word_once(),
> vma_flags_set_word() and vma_flags_clear_word() in order to allow us to
> update the existing vm_flags_*() functions to utilise these helpers.
> 
> This is a stepping stone towards converting users to the VMA flags bitmap
> and behaves precisely as before.
> 
> By doing this, we can eliminate the existing private vma->__vm_flags field
> in the vma->vm_flags union and replace it with the newly introduced opaque
> type vma_flags, which we call flags so we refer to the new bitmap field as
> vma->flags.
> 
> We update vma_flag_[test, set]_atomic() to account for the change also.
> 
> We adapt vm_flags_reset_once() to only clear those bits above the first
> system word providing write-once semantics to the first system word (which
> it is presumed the caller requires - and in all current use cases this is
> so).
> 
> As we currently only specify that the VMA flags bitmap size is equal to
> BITS_PER_LONG number of bits, this is a noop, but is defensive in
> preparation for a future change that increases this.
> 
> We additionally update the VMA userland test declarations to implement the
> same changes there.
> 
> Finally, we update the rust code to reference vma->vm_flags on update
> rather than vma->__vm_flags which has been removed. This is safe for now,
> albeit it is implicitly performing a const cast.
> 
> Once we introduce flag helpers we can improve this more.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> Acked-by: Vlastimil Babka <vbabka@...e.cz>

FWIW, I'm not a huge fan of this vma_flags vs vm_flags and hope we can
get rid of this ASAP. But it's a necessary evil for now, anyway.

Reviewed-by: Pedro Falcato <pfalcato@...e.de>

-- 
Pedro

Powered by blists - more mailing lists