On Fri, May 29, 2026 at 05:09:56PM +0100, Kiryl Shutsemau wrote:
> On Fri, May 29, 2026 at 03:00:14PM +0100, Lorenzo Stoakes wrote:
> > > Add VMA_NO_BIT and have DECLARE_VMA_BIT() resolve any bitnum out
> > > of range to it. vma_flags_set_flag() drops negative bit values.
> > > The ternary collapses at compile time, the runtime check folds
> > > away when the bit is in range, and the common path is unchanged.
> >
> > Hmm are you sure it does?
>
> You were right - I measured it (gcc 15.2, clang 21.1.8, -O2). The
> DECLARE_VMA_BIT() ternary is fine, but the "if (bit < 0)" guard does not
> reliably fold: with it, clang stops folding __VMA_UFFD_FLAGS to a constant
> and gcc keeps a rolled loop; without it, both fold.
>
> So I've dropped VMA_NO_BIT and gone with your config-gated-mask approach
> instead: mk_vma_flags_from_masks() plus VMA_UFFD_{MISSING,WP,MINOR,RWP}
> masks that collapse to EMPTY_VMA_FLAGS when unavailable, so no out-of-range
> bit ever reaches mk_vma_flags(). __VMA_UFFD_FLAGS now folds to a single
> constant on both compilers, 32- and 64-bit. Added your Suggested-by.
>
> I also took your "use the new API" hint and added a prep patch converting
> the existing userfaultfd_*() helpers to vma_test_any_mask() (Suggested-by
> you as well). One deviation: vma_test(vma, VMA_UFFD_RWP_BIT) is itself an
> out-of-bounds *read* on 32-bit (test_bit(43, &one_long)), so the helpers
> use vma_test_any_mask() with the masks rather than the bit.
>
> > Either way, I think we should break out any fix like this from the series.
>
> Agreed - the OOB fix and the other pre-existing fixes will go as a separate
> series with the RWP work rebased on top.Ack on all and thanks! :) > > -- > Kiryl Shutsemau / Kirill A. Shutemov Cheers, Lorenzo
