Message-ID: <cover.1761757731.git.lorenzo.stoakes@oracle.com>
Date: Wed, 29 Oct 2025 17:49:34 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: 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>, Pedro Falcato <pfalcato@...e.de>,
        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
Subject: [PATCH 0/4] initial work on making VMA flags a bitmap

We are in the rather silly situation that we are running out of VMA flags
as they are currently limited to a system word in size.

This leads to absurd situations where we limit features to 64-bit
architectures only because we simply do not have the ability to add a flag
for 32-bit ones.

This is very constraining and leads to hacks or, in the worst case, simply
an inability to implement features we want for entirely arbitrary reasons.

This also of course gives us something of a Y2K type situation in mm where
we might eventually exhaust all of the VMA flags even on 64-bit systems.

This series lays the groundwork for getting away from this limitation by
establishing VMA flags as a bitmap whose size we can increase in future
beyond 64 bits if required.

This is necessarily a highly iterative process given the extensive use of
VMA flags throughout the kernel, so we start by performing basic steps.

Firstly, we declare VMA flags by bit number rather than by value, retaining
the VM_xxx fields but in terms of these newly introduced VMA_xxx_BIT
fields.

While we are here, we use sparse annotations to ensure that, when dealing
with VMA bit number parameters, we cannot be passed values which are not
declared as such - providing some useful type safety.

We then introduce an opaque VMA flag type, much like the opaque mm_struct
flag type introduced in commit bb6525f2f8c4 ("mm: add bitmap mm->flags
field"), which we establish in union with vma->vm_flags (but still set at
system word size meaning there is no functional or data type size change).

We update the vm_flags_xxx() helpers to use this new bitmap, introducing
sensible helpers to do so.

We then provide vma_flags_test() and vma_test() to allow for testing of VMA
flag bits, and utilise these across the memory management subsystem.

Since it would be entirely inefficient to do away with the bitwise
operations used throughout the kernel with respect to VMA flags, we permit
these to exist, providing helpers for these operations against the new
bitmap.

These operate on the assumption that such operations will only be required
for flags which can exist within a system word. This allows the fundamental
flags to be used efficiently as before.

This series lays the foundation for further work to expand the use of
bitmap VMA flags and eventually eliminate these arbitrary restrictions.


ANDREW/REVIEWS NOTES:

Apologies, but the nature of this series is that it's going to be a little
painful, I've based it on [0] to make life a bit easier. Let me know if you
need rebases etc.

[0]: https://lore.kernel.org/linux-mm/cover.1761756437.git.lorenzo.stoakes@oracle.com/

Lorenzo Stoakes (4):
  mm: declare VMA flags by bit
  mm: simplify and rename mm flags function for clarity
  mm: introduce VMA flags bitmap type
  mm: introduce and use VMA flag test helpers

 fs/proc/task_mmu.c               |   4 +-
 include/linux/hugetlb.h          |   2 +-
 include/linux/mm.h               | 341 +++++++++++++-------
 include/linux/mm_inline.h        |   2 +-
 include/linux/mm_types.h         | 120 ++++++-
 include/linux/userfaultfd_k.h    |  12 +-
 kernel/fork.c                    |   4 +-
 mm/filemap.c                     |   4 +-
 mm/gup.c                         |  16 +-
 mm/hmm.c                         |   6 +-
 mm/huge_memory.c                 |  34 +-
 mm/hugetlb.c                     |  48 +--
 mm/internal.h                    |   8 +-
 mm/khugepaged.c                  |   2 +-
 mm/ksm.c                         |  12 +-
 mm/madvise.c                     |   8 +-
 mm/memory.c                      |  77 +++--
 mm/mempolicy.c                   |   4 +-
 mm/migrate.c                     |   4 +-
 mm/migrate_device.c              |  10 +-
 mm/mlock.c                       |   8 +-
 mm/mmap.c                        |  16 +-
 mm/mmap_lock.c                   |   4 +-
 mm/mprotect.c                    |  12 +-
 mm/mremap.c                      |  18 +-
 mm/mseal.c                       |   2 +-
 mm/msync.c                       |   4 +-
 mm/nommu.c                       |  16 +-
 mm/oom_kill.c                    |   4 +-
 mm/pagewalk.c                    |   2 +-
 mm/rmap.c                        |  16 +-
 mm/swap.c                        |   3 +-
 mm/userfaultfd.c                 |  33 +-
 mm/vma.c                         |  37 ++-
 mm/vma.h                         |   6 +-
 mm/vmscan.c                      |   4 +-
 tools/testing/vma/vma.c          |  20 +-
 tools/testing/vma/vma_internal.h | 536 +++++++++++++++++++++++++++----
 38 files changed, 1037 insertions(+), 422 deletions(-)

--
2.51.0

Powered by blists - more mailing lists