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

[Jakub Acs <acsjakub@amazon.de>]

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