[akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[kernel test robot]

Hi Jakub,

FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
head:   70478cb9da6fc4e7b987219173ba1681d5f7dd3d
commit: da4dbad77af8cc850a570fd05455369cc12b0be4 [36/102] mm: redefine VM_* flag constants with BIT()
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20251010/202510100127.yuqhg8uo-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251010/202510100127.yuqhg8uo-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510100127.yuqhg8uo-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/sched/rq-offsets.c:5:
   kernel/sched/sched.h:3743:18: warning: variable 'cpumask' set but not used [-Wunused-but-set-variable]
   3743 |         struct cpumask *cpumask;
   |                         ^
   1 warning generated.
>> 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_DONTCOPY` in crate `bindings`
   --> rust/kernel/mm/virt.rs:429:48
   |
   429 |     pub const DONTCOPY: vm_flags_t = bindings::VM_DONTCOPY as vm_flags_t;
   |                                                ^^^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_DONTEXPAND` in crate `bindings`
   --> rust/kernel/mm/virt.rs:432:50
   |
   432 |     pub const DONTEXPAND: vm_flags_t = bindings::VM_DONTEXPAND as vm_flags_t;
   |                                                  ^^^^^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_LOCKONFAULT` in crate `bindings`
   --> rust/kernel/mm/virt.rs:435:51
   |
   435 |     pub const LOCKONFAULT: vm_flags_t = bindings::VM_LOCKONFAULT as vm_flags_t;
   |                                                   ^^^^^^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_ACCOUNT` in crate `bindings`
   --> rust/kernel/mm/virt.rs:438:47
   |
   438 |     pub const ACCOUNT: vm_flags_t = bindings::VM_ACCOUNT as vm_flags_t;
   |                                               ^^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_NORESERVE` in crate `bindings`
   --> rust/kernel/mm/virt.rs:441:49
   |
   441  |     pub const NORESERVE: vm_flags_t = bindings::VM_NORESERVE as vm_flags_t;
   |                                                 ^^^^^^^^^^^^ help: a constant with a similar name exists: `SHN_LORESERVE`
   |
   ::: rust/bindings/bindings_generated.rs:8477:1
   |
   8477 | pub const SHN_LORESERVE: u32 = 65280;
   | ---------------------------- similarly named constant `SHN_LORESERVE` defined here
--
>> error[E0425]: cannot find value `VM_HUGETLB` in crate `bindings`
   --> rust/kernel/mm/virt.rs:444:47
   |
   444 |     pub const HUGETLB: vm_flags_t = bindings::VM_HUGETLB as vm_flags_t;
   |                                               ^^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_SYNC` in crate `bindings`
   --> rust/kernel/mm/virt.rs:447:44
   |
   447   |     pub const SYNC: vm_flags_t = bindings::VM_SYNC as vm_flags_t;
   |                                            ^^^^^^^ help: a constant with a similar name exists: `O_SYNC`
   |
   ::: rust/bindings/bindings_generated.rs:10666:1
   |
   10666 | pub const O_SYNC: u32 = 1052672;
   | --------------------- similarly named constant `O_SYNC` defined here
--
>> error[E0425]: cannot find value `VM_ARCH_1` in crate `bindings`
   --> rust/kernel/mm/virt.rs:450:46
   |
   450 |     pub const ARCH_1: vm_flags_t = bindings::VM_ARCH_1 as vm_flags_t;
   |                                              ^^^^^^^^^ not found in `bindings`
--
>> error[E0425]: cannot find value `VM_WIPEONFORK` in crate `bindings`
   --> rust/kernel/mm/virt.rs:453:50
   |
   453 |     pub const WIPEONFORK: vm_flags_t = bindings::VM_WIPEONFORK as vm_flags_t;
   |                                                  ^^^^^^^^^^^^^ not found in `bindings`
..

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Andrew Morton]

On Fri, 10 Oct 2025 01:42:21 +0800 kernel test robot <lkp@intel.com> wrote:

> Hi Jakub,
> 
> FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
> head:   70478cb9da6fc4e7b987219173ba1681d5f7dd3d
> commit: da4dbad77af8cc850a570fd05455369cc12b0be4 [36/102] mm: redefine VM_* flag constants with BIT()
> config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20251010/202510100127.yuqhg8uo-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251010/202510100127.yuqhg8uo-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202510100127.yuqhg8uo-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>    In file included from kernel/sched/rq-offsets.c:5:
>    kernel/sched/sched.h:3743:18: warning: variable 'cpumask' set but not used [-Wunused-but-set-variable]
>    3743 |         struct cpumask *cpumask;
>    |                         ^
>    1 warning generated.
> >> 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`

Argh.

Alice, Miguel, please remind what to do about this?

I'll disable Jakub's patch for now.

Thanks.


From: Jakub Acs <acsjakub@amazon.de>
Subject: mm: redefine VM_* flag constants with BIT()
Date: Thu, 2 Oct 2025 07:52:02 +0000

Make VM_* flag constant definitions consistent - unify all to use BIT()
macro.

We have previously changed VM_MERGEABLE in a separate bugfix.  This is a
follow-up to make all the VM_* flag constant definitions consistent, as
suggested by David in [1].

Link: https://lkml.kernel.org/r/20251002075202.11306-1-acsjakub@amazon.de
Link: https://lore.kernel.org/all/85f852f9-8577-4230-adc7-c52e7f479454@redhat.com/ [1]
Signed-off-by: Jakub Acs <acsjakub@amazon.de>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: SeongJae Park <sj@kernel.org>
Cc: Xu Xin <xu.xin16@zte.com.cn>
Cc: Chengming Zhou <chengming.zhou@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chengming Zhou <chengming.zhou@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: xu xin <xu.xin16@zte.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/mm.h |   64 +++++++++++++++++++++----------------------
 1 file changed, 32 insertions(+), 32 deletions(-)

--- a/include/linux/mm.h~mm-redefine-vm_-flag-constants-with-bit
+++ a/include/linux/mm.h
@@ -273,56 +273,56 @@ extern unsigned int kobjsize(const void
  * vm_flags in vm_area_struct, see mm_types.h.
  * When changing, update also include/trace/events/mmflags.h
  */
-#define VM_NONE		0x00000000
+#define VM_NONE		0
 
-#define VM_READ		0x00000001	/* currently active flags */
-#define VM_WRITE	0x00000002
-#define VM_EXEC		0x00000004
-#define VM_SHARED	0x00000008
+#define VM_READ		BIT(0)		/* currently active flags */
+#define VM_WRITE	BIT(1)
+#define VM_EXEC		BIT(2)
+#define VM_SHARED	BIT(3)
 
 /* mprotect() hardcodes VM_MAYREAD >> 4 == VM_READ, and so for r/w/x bits. */
-#define VM_MAYREAD	0x00000010	/* limits for mprotect() etc */
-#define VM_MAYWRITE	0x00000020
-#define VM_MAYEXEC	0x00000040
-#define VM_MAYSHARE	0x00000080
+#define VM_MAYREAD	BIT(4)		/* limits for mprotect() etc */
+#define VM_MAYWRITE	BIT(5)
+#define VM_MAYEXEC	BIT(6)
+#define VM_MAYSHARE	BIT(7)
 
-#define VM_GROWSDOWN	0x00000100	/* general info on the segment */
+#define VM_GROWSDOWN	BIT(8)		/* general info on the segment */
 #ifdef CONFIG_MMU
-#define VM_UFFD_MISSING	0x00000200	/* missing pages tracking */
+#define VM_UFFD_MISSING	BIT(9)		/* missing pages tracking */
 #else /* CONFIG_MMU */
-#define VM_MAYOVERLAY	0x00000200	/* nommu: R/O MAP_PRIVATE mapping that might overlay a file mapping */
+#define VM_MAYOVERLAY	BIT(9)		/* nommu: R/O MAP_PRIVATE mapping that might overlay a file mapping */
 #define VM_UFFD_MISSING	0
 #endif /* CONFIG_MMU */
-#define VM_PFNMAP	0x00000400	/* Page-ranges managed without "struct page", just pure PFN */
-#define VM_UFFD_WP	0x00001000	/* wrprotect pages tracking */
+#define VM_PFNMAP	BIT(10)		/* Page-ranges managed without "struct page", just pure PFN */
+#define VM_UFFD_WP	BIT(12)		/* wrprotect pages tracking */
 
-#define VM_LOCKED	0x00002000
-#define VM_IO           0x00004000	/* Memory mapped I/O or similar */
+#define VM_LOCKED	BIT(13)
+#define VM_IO           BIT(14)		/* Memory mapped I/O or similar */
 
 					/* Used by sys_madvise() */
-#define VM_SEQ_READ	0x00008000	/* App will access data sequentially */
-#define VM_RAND_READ	0x00010000	/* App will not benefit from clustered reads */
+#define VM_SEQ_READ	BIT(15)		/* App will access data sequentially */
+#define VM_RAND_READ	BIT(16)		/* App will not benefit from clustered reads */
 
-#define VM_DONTCOPY	0x00020000      /* Do not copy this vma on fork */
-#define VM_DONTEXPAND	0x00040000	/* Cannot expand with mremap() */
-#define VM_LOCKONFAULT	0x00080000	/* Lock the pages covered when they are faulted in */
-#define VM_ACCOUNT	0x00100000	/* Is a VM accounted object */
-#define VM_NORESERVE	0x00200000	/* should the VM suppress accounting */
-#define VM_HUGETLB	0x00400000	/* Huge TLB Page VM */
-#define VM_SYNC		0x00800000	/* Synchronous page faults */
-#define VM_ARCH_1	0x01000000	/* Architecture-specific flag */
-#define VM_WIPEONFORK	0x02000000	/* Wipe VMA contents in child. */
-#define VM_DONTDUMP	0x04000000	/* Do not include in the core dump */
+#define VM_DONTCOPY	BIT(17)		/* Do not copy this vma on fork */
+#define VM_DONTEXPAND	BIT(18)		/* Cannot expand with mremap() */
+#define VM_LOCKONFAULT	BIT(19)		/* Lock the pages covered when they are faulted in */
+#define VM_ACCOUNT	BIT(20)		/* Is a VM accounted object */
+#define VM_NORESERVE	BIT(21)		/* should the VM suppress accounting */
+#define VM_HUGETLB	BIT(22)		/* Huge TLB Page VM */
+#define VM_SYNC		BIT(23)		/* Synchronous page faults */
+#define VM_ARCH_1	BIT(24)		/* Architecture-specific flag */
+#define VM_WIPEONFORK	BIT(25)		/* Wipe VMA contents in child. */
+#define VM_DONTDUMP	BIT(26)		/* Do not include in the core dump */
 
 #ifdef CONFIG_MEM_SOFT_DIRTY
-# define VM_SOFTDIRTY	0x08000000	/* Not soft dirty clean area */
+# define VM_SOFTDIRTY	BIT(27)		/* Not soft dirty clean area */
 #else
 # define VM_SOFTDIRTY	0
 #endif
 
-#define VM_MIXEDMAP	0x10000000	/* Can contain "struct page" and pure PFN pages */
-#define VM_HUGEPAGE	0x20000000	/* MADV_HUGEPAGE marked this vma */
-#define VM_NOHUGEPAGE	0x40000000	/* MADV_NOHUGEPAGE marked this vma */
+#define VM_MIXEDMAP	BIT(28)		/* Can contain "struct page" and pure PFN pages */
+#define VM_HUGEPAGE	BIT(29)		/* MADV_HUGEPAGE marked this vma */
+#define VM_NOHUGEPAGE	BIT(30)		/* MADV_NOHUGEPAGE marked this vma */
 #define VM_MERGEABLE	BIT(31)		/* KSM may merge identical pages */
 
 #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS
_

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Thu, Oct 9, 2025 at 8:05 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Alice, Miguel, please remind what to do about this?

We can either define helper constants in
`rust/bindings/bindings_helper.h` for the ones that the Rust side is
already using (like last time) or use `enum`s on the C header.

If you have it in a branch, I can prepare a quick diff for you to fold.

Cheers,
Miguel

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Thu, Oct 9, 2025 at 8:14 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> We can either define helper constants in
> `rust/bindings/bindings_helper.h` for the ones that the Rust side is
> already using (like last time) or use `enum`s on the C header.
>
> If you have it in a branch, I can prepare a quick diff for you to fold.

Should I test on
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new?

Cheers,
Miguel

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Andrew Morton]

On Thu, 9 Oct 2025 20:15:06 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Thu, Oct 9, 2025 at 8:14 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > We can either define helper constants in
> > `rust/bindings/bindings_helper.h` for the ones that the Rust side is
> > already using (like last time) or use `enum`s on the C header.
> >
> > If you have it in a branch, I can prepare a quick diff for you to fold.
> 
> Should I test on
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new?
> 

Yes please.  That's the only place where this patch is hosted.

mm-new is for "new" material and is held out of linux-next until the
end of the merge window.

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Jakub Acs]

On Thu, Oct 09, 2025 at 08:14:01PM +0200, Miguel Ojeda wrote:
> On Thu, Oct 9, 2025 at 8:05 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > Alice, Miguel, please remind what to do about this?
> 
> We can either define helper constants in
> `rust/bindings/bindings_helper.h` for the ones that the Rust side is
> already using (like last time) or use `enum`s on the C header.

FWIW Alice suggested the enum version and we discussed adjustment to the
patch in thread [1]. I was going to send new version of the patch as
soon as I figure out how to test for the issue pointed out by Derrick in
[2].

Please let me know if that is desired or whether you're taking care of
it here. And/or how else I can help.


[1]: https://lore.kernel.org/all/20251008125427.68735-1-acsjakub@amazon.de/
[2]: https://lore.kernel.org/all/20251007170156.GQ1587915@frogsfrogsfrogs/

Thanks,
Jakub



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Fri, Oct 10, 2025 at 8:07 AM Jakub Acs <acsjakub@amazon.de> wrote:
>
> FWIW Alice suggested the enum version and we discussed adjustment to the
> patch in thread [1]. I was going to send new version of the patch as
> soon as I figure out how to test for the issue pointed out by Derrick in
> [2].
>
> Please let me know if that is desired or whether you're taking care of
> it here. And/or how else I can help.

The `enum` approach is what we usually suggest if possible, and in
this case it also avoids having to replicate conditional compilation
on the Rust side, which is good.

However, using it here as-is means the resulting type of
`VM_MERGEABLE` is `unsigned int`, not `unsigned long` -- but wasn't
that an issue? i.e.

    https://lore.kernel.org/all/20250930130023.60106-1-acsjakub@amazon.de/

We may be able to use a dummy larger constant to force the compiler to
pick a bigger underlying type, e.g. something like:

    __VM_FLAGS_FORCE_UL    = BIT(63),

But note that older versions of GCC and Clang keep the smaller `enum`
constants as `int` (i.e. small and signed), even if they will pick
`unsigned long` for the bigger ones. Newer versions will pick
`unsigned long` for all.

The best would be to use C23-like `enum : unsigned long { ... }`, but
sadly we don't have a recent enough GCC as a minimum in the kernel
(GCC 13).

If there are extra complications with the `enum` approach (i.e. second
link), then perhaps just replicating it on the Rust side is simpler.

Cheers,
Miguel

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Jakub Acs]

On Fri, Oct 10, 2025 at 08:59:06AM +0200, Miguel Ojeda wrote:
> On Fri, Oct 10, 2025 at 8:07 AM Jakub Acs <acsjakub@amazon.de> wrote:
> >
> > FWIW Alice suggested the enum version and we discussed adjustment to the
> > patch in thread [1]. I was going to send new version of the patch as
> > soon as I figure out how to test for the issue pointed out by Derrick in
> > [2].
> >
> > Please let me know if that is desired or whether you're taking care of
> > it here. And/or how else I can help.
> 
> The `enum` approach is what we usually suggest if possible, and in
> this case it also avoids having to replicate conditional compilation
> on the Rust side, which is good.
> 
> However, using it here as-is means the resulting type of
> `VM_MERGEABLE` is `unsigned int`, not `unsigned long` -- but wasn't
> that an issue? i.e.
> 
>     https://lore.kernel.org/all/20250930130023.60106-1-acsjakub@amazon.de/
> 

This is a tricky one - VM_MERGEABLE being `unsigned int` is only an issue
if there are flags using any of the upper 32 bits. And if that is the
case, CONFIG_ARCH_USES_HIGH_VMA_FLAGS has to be 'y', -> thus the enum
will also have BIT(33), BIT(34), and so on. So from that perspective
we're ok (checked by running a reproducer).

> We may be able to use a dummy larger constant to force the compiler to
> pick a bigger underlying type, e.g. something like:
> 
>     __VM_FLAGS_FORCE_UL    = BIT(63),
> 
> But note that older versions of GCC and Clang keep the smaller `enum`
> constants as `int` (i.e. small and signed), even if they will pick
> `unsigned long` for the bigger ones. Newer versions will pick
> `unsigned long` for all.
> 
> The best would be to use C23-like `enum : unsigned long { ... }`, but
> sadly we don't have a recent enough GCC as a minimum in the kernel
> (GCC 13).
> 
> If there are extra complications with the `enum` approach (i.e. second
> link), then perhaps just replicating it on the Rust side is simpler.
> 

This ofc remains true, I'm not yet sure how to test that complication.

Thanks,
Jakub



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Fri, Oct 10, 2025 at 8:59 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> The best would be to use C23-like `enum : unsigned long { ... }`, but
> sadly we don't have a recent enough GCC as a minimum in the kernel
> (GCC 13).

The `mode` attribute also influences the `enum` constants -- doing
something like:

    enum { ... } __mode(pointer);

will make `VM_MERGEABLE` either `long` or `unsigned long` depending on
the compiler and version.

So with:

    #ifdef __clang__
        #define __unsigned_long_enum : unsigned long
    #else
        #define __unsigned_long_enum __mode(pointer)
    #endif

And then using it like:

    enum __unsigned_long_enum { ... };

I can get quite close: old GCC will use `int` for smaller constants
and `unsigned long` for the bigger ones, and everything else (new GCC
and all Clangs) will use `unsigned long` for everything.

Perhaps this may be useful on its own for C in some cases.

Cheers,
Miguel

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Fri, Oct 10, 2025 at 9:45 AM Jakub Acs <acsjakub@amazon.de> wrote:
>
> This is a tricky one - VM_MERGEABLE being `unsigned int` is only an issue
> if there are flags using any of the upper 32 bits. And if that is the
> case, CONFIG_ARCH_USES_HIGH_VMA_FLAGS has to be 'y', -> thus the enum
> will also have BIT(33), BIT(34), and so on. So from that perspective
> we're ok (checked by running a reproducer).

Ah, good, that simplifies things, yeah. A comment about the fact that
we rely on higher ones existing on the enum may make sense to add.

Or, even better, an static assert testing the type of `VM_MERGEABLE`.

> This ofc remains true, I'm not yet sure how to test that complication.

If we keep the macros, then I was thinking we can avoid replicating a
bit of conditional compilation elsewhere by blackboxing the zeros,
e.g.

    # define VM_SOFTDIRTY  BINDGEN_BLACKBOX(0)

That way we can keep dummier lists on the Rust helpers. But it does
look a bit out of place (though it is a smaller change than the whole
`enum` thing).

Otherwise, for the moment we can go with [1]. It is just a single `#ifdef`.

Cheers,
Miguel

[1]

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 2e43c66635a2..3c3a03051060 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -108,6 +108,33 @@ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;

 const gfp_t RUST_CONST_HELPER_XA_FLAGS_ALLOC = XA_FLAGS_ALLOC;
 const gfp_t RUST_CONST_HELPER_XA_FLAGS_ALLOC1 = XA_FLAGS_ALLOC1;
+
+const vm_flags_t RUST_CONST_HELPER_VM_READ = VM_READ;
+const vm_flags_t RUST_CONST_HELPER_VM_WRITE = VM_WRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_EXEC = VM_EXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_SHARED = VM_SHARED;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYREAD = VM_MAYREAD;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYWRITE = VM_MAYWRITE;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYEXEC = VM_MAYEXEC;
+const vm_flags_t RUST_CONST_HELPER_VM_MAYSHARE = VM_MAYSHARE;
+const vm_flags_t RUST_CONST_HELPER_VM_PFNMAP = VM_PFNMAP;
+const vm_flags_t RUST_CONST_HELPER_VM_IO = VM_IO;
+const vm_flags_t RUST_CONST_HELPER_VM_DONTCOPY = VM_DONTCOPY;
+const vm_flags_t RUST_CONST_HELPER_VM_DONTEXPAND = VM_DONTEXPAND;
+const vm_flags_t RUST_CONST_HELPER_VM_LOCKONFAULT = VM_LOCKONFAULT;
+const vm_flags_t RUST_CONST_HELPER_VM_ACCOUNT = VM_ACCOUNT;
+const vm_flags_t RUST_CONST_HELPER_VM_NORESERVE = VM_NORESERVE;
+const vm_flags_t RUST_CONST_HELPER_VM_HUGETLB = VM_HUGETLB;
+const vm_flags_t RUST_CONST_HELPER_VM_SYNC = VM_SYNC;
+const vm_flags_t RUST_CONST_HELPER_VM_ARCH_1 = VM_ARCH_1;
+const vm_flags_t RUST_CONST_HELPER_VM_WIPEONFORK = VM_WIPEONFORK;
+const vm_flags_t RUST_CONST_HELPER_VM_DONTDUMP = VM_DONTDUMP;
+#ifdef CONFIG_MEM_SOFT_DIRTY
+const vm_flags_t RUST_CONST_HELPER_VM_SOFTDIRTY = VM_SOFTDIRTY;
+#endif
+const vm_flags_t RUST_CONST_HELPER_VM_MIXEDMAP = VM_MIXEDMAP;
+const vm_flags_t RUST_CONST_HELPER_VM_HUGEPAGE = VM_HUGEPAGE;
+const vm_flags_t RUST_CONST_HELPER_VM_NOHUGEPAGE = VM_NOHUGEPAGE;
 const vm_flags_t RUST_CONST_HELPER_VM_MERGEABLE = VM_MERGEABLE;

 #if IS_ENABLED(CONFIG_ANDROID_BINDER_IPC_RUST)

Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda]

On Fri, Oct 10, 2025 at 10:13 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Otherwise, for the moment we can go with [1]. It is just a single `#ifdef`.

And if this becomes a bigger deal before we can start applying
`bindgen`'s feature for this, we can always look into imitating
`bindgen` to fetch the values on our own, i.e. with an extra step in
the build or similar. It wouldn't be the first time we do things like
that...

Cheers,
Miguel