lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA1CXcCiS37Kw78pam3=htBX5FvtbFOWvYNA0nPWLyE93HPtwA@mail.gmail.com>
Date: Wed, 29 Oct 2025 21:07:07 -0600
From: Nico Pache <npache@...hat.com>
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>, 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: Re: [PATCH 0/4] initial work on making VMA flags a bitmap

On Wed, Oct 29, 2025 at 11:50 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> 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.

Hey Lorenzo,

I put your patchset into the Fedora Koji system to run some CI on it for you.

It failed to build due to what looks like some Rust bindings.

Heres the build: https://koji.fedoraproject.org/koji/taskinfo?taskID=138547842

And x86 build logs:
https://kojipkgs.fedoraproject.org//work/tasks/7966/138547966/build.log

The error is pretty large but here's a snippet if you want an idea

error[E0425]: cannot find value `VM_READ` in crate `bindings`
   --> rust/kernel/mm/virt.rs:399:44
    |
399 |     pub const READ: vm_flags_t = bindings::VM_READ as vm_flags_t;
    |                                            ^^^^^^^ not found in `bindings`
error[E0425]: cannot find value `VM_WRITE` in crate `bindings`
   --> rust/kernel/mm/virt.rs:402:45
    |
402 |     pub const WRITE: vm_flags_t = bindings::VM_WRITE as vm_flags_t;
    |                                             ^^^^^^^^ not found
in `bindings`
error[E0425]: cannot find value `VM_EXEC` in crate `bindings`
     --> rust/kernel/mm/virt.rs:405:44
      |
  405 |     pub const EXEC: vm_flags_t = bindings::VM_EXEC as vm_flags_t;
      |                                            ^^^^^^^ help: a
constant with a similar name exists: `ET_EXEC`
      |
     ::: /builddir/build/BUILD/kernel-6.18.0-build/kernel-6.18-rc3-16-ge53642b87a4f/linux-6.18.0-0.rc3.e53642b87a4f.31.bitvma.fc44.x86_64/rust/bindings/bindings_generated.rs:13881:1
      |
13881 | pub const ET_EXEC: u32 = 2;
      | ---------------------- similarly named constant `ET_EXEC` defined here
error[E0425]: cannot find value `VM_SHARED` in crate `bindings`
   --> rust/kernel/mm/virt.rs:408:46
    |
408 |     pub const SHARED: vm_flags_t = bindings::VM_SHARED as vm_flags_t;
    |                                              ^^^^^^^^^ not found
in `bindings`

In the next version Ill do the same and continue with the CI testing for you!

Cheers,
-- Nico

>
> [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

Powered by Openwall GNU/*/Linux Powered by OpenVZ