Message-ID: <aXkv7DSUbdY-RD5d@yury>
Date: Tue, 27 Jan 2026 16:36:44 -0500
From: Yury Norov <ynorov@...dia.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, x86@...nel.org,
	"H . Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Tvrtko Ursulin <tursulin@...ulin.net>,
	Christian Koenig <christian.koenig@....com>,
	Huang Rui <ray.huang@....com>,
	Matthew Auld <matthew.auld@...el.com>,
	Matthew Brost <matthew.brost@...el.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Benjamin LaHaise <bcrl@...ck.org>, Gao Xiang <xiang@...nel.org>,
	Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
	Jeffle Xu <jefflexu@...ux.alibaba.com>,
	Sandeep Dhavale <dhavale@...gle.com>,
	Hongbo Li <lihongbo22@...wei.com>,
	Chunhai Guo <guochunhai@...o.com>, Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Muchun Song <muchun.song@...ux.dev>,
	Oscar Salvador <osalvador@...e.de>,
	David Hildenbrand <david@...nel.org>,
	Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
	Mike Marshall <hubcap@...ibond.com>,
	Martin Brandenburg <martin@...ibond.com>,
	Tony Luck <tony.luck@...el.com>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Dave Martin <Dave.Martin@....com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>,
	Carlos Maiolino <cem@...nel.org>,
	Damien Le Moal <dlemoal@...nel.org>,
	Naohiro Aota <naohiro.aota@....com>,
	Johannes Thumshirn <jth@...nel.org>,
	Matthew Wilcox <willy@...radead.org>,
	"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>, Hugh Dickins <hughd@...gle.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Zi Yan <ziy@...dia.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>,
	Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
	David Howells <dhowells@...hat.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E . Hallyn" <serge@...lyn.com>,
	Yury Norov <yury.norov@...il.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
	nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
	linux-fsdevel@...r.kernel.org, linux-aio@...ck.org,
	linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org,
	linux-mm@...ck.org, ntfs3@...ts.linux.dev, devel@...ts.orangefs.org,
	linux-xfs@...r.kernel.org, keyrings@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Jason Gunthorpe <jgg@...dia.com>
Subject: Re: [PATCH v2 00/13] mm: add bitmap VMA flag helpers and convert all
 mmap_prepare to use them

On Tue, Jan 27, 2026 at 02:40:03PM +0000, Lorenzo Stoakes wrote:
> On Tue, Jan 27, 2026 at 08:53:44AM -0500, Yury Norov wrote:
> > On Thu, Jan 22, 2026 at 04:06:09PM +0000, Lorenzo Stoakes wrote:

...

> > Even if you expect adding more flags, u128 would double your capacity,
> > and people will still be able to use language-supported operation on
> > the bits in flag. Which looks simpler to me...
> 
> u128 isn't supported on all architectures, VMA flags have to have absolutely
 
What about big integers?

        typedef unsigned _BitInt(VMA_FLAGS_COUNT) vma_flags_t

> We want to be able to arbitrarily extend this as we please in the future. So
> using u64 wouldn't buy us _anything_ except getting the 32-bit kernels in line.

So enabling 32-bit arches is a big deal, even if it's a temporary
solution. Again, how many flags in your opinion are blocked because of
32-bit integer limitation? How soon 64-bit capacity will get fully
used?

> Using an integral value doesn't give us any kind of type safety, nor does it
> give us as easy a means to track what users are doing with flags - both
> additional benefits of this change.

I tried the below, and it works OK for me with i386:

$ cat bi.c
#include <stdio.h>
#include <limits.h>

int main() {
    unsigned _BitInt(128) a = (_BitInt(128))1 << 65;
    unsigned _BitInt(128) b = (_BitInt(128))1 << 66;

    printf("a | b == %llx\n", (unsigned long long)((a | b)>>64));
    printf("BITINT_MAXWIDTH ==  0x%x\n", BITINT_MAXWIDTH);

    return 0;
}

$ clang -m32 -std=c2x bi.c
$ ./a.out
a | b == 6
BITINT_MAXWIDTH == 0x800000

I didn't make GCC building it, at least out of the box. So the above
question about 64-bit capacity has a practical meaning. If we've got a
few years to let GCC fully support big integers as clang does, we don't 
have to wish anything else.

I'd like to put it right. I maintain bitmaps, and I like it widely
adopted. But when it comes to flags, being able to use plain logic
operations looks so important to me so I'd like to make sure that
switching to bitmaps is the only working option.

Powered by blists - more mailing lists