[PATCH 1/3] mm: change vm_get_page_prot() to accept vm_flags_t argument

[Lorenzo Stoakes]

On Thu, Jun 19, 2025 at 10:42:14AM +0200, Christian Brauner wrote:
> If you change vm_flags_t to u64 you probably want to compile with some
> of these integer truncation options when you're doing the conversion.
> Because otherwise you risk silently truncating the upper 32bits when
> assigning to a 32bit variable. We've had had a patch series that almost
> introduced a very subtle bug when it tried to add the first flag outside
> the 32bit range in the lookup code a while ago. That series never made
> it but it just popped back into my head when I read your series.

Yeah am very wary of this, it's a real concern. I'm not sure how precisely we
might enable such options but only in this instance? Because presumably we are
intentionally narrowing in probably quite a few places.

Pedro mentioned that there might be compiler options to help so I'm guessing
this is the same thing as to what you're thinking here?

I also considered a sparse flag, Pedro mentioned bitwise, but then I worry that
we'd have to __force in a million places to make that work and it'd be
non-obvious.

Matthew's original concept for this was to simply wrap an array, but that'd
require a complete rework of every single place where we use VMA flags (perhaps
we could mitigate it a _bit_ with a vm_flags_val() helper that grabs a u64?)

Something like this would be safest, but might be a lot of churn even for me ;)

The 'quickest' solution is to use u64 and somehow have a means of telling the
compiler 'error out if anybody narrows this'.

At any rate, I've gone with doing the safest thing _first_ which is to fixup use
of this typedef and neatly deferred all these messy decisions until later :>)

I am likely to fiddle around with the different proposed solutions and find the
most workable.

But I think overall we need _something_ here.

>
> Acked-by: Christian Brauner <brauner at kernel.org>
>

Thanks!