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@kernel.org>
Thanks!