On Mon, Oct 12, 2026 at 08:51:10PM +0200, David Hildenbrand (Arm) wrote:
> On 10/12/26 20:48, Lorenzo Stoakes (ARM) wrote:
> > On Mon, Oct 12, 2026 at 08:39:35PM +0200, David Hildenbrand (Arm) wrote:
> >> On 10/12/26 20:35, Lorenzo Stoakes (ARM) wrote:
> >>>
> >>> That gets removed.
> >>>
> >>>
> >>> I mean we do that in a subsequent commit, I think even the next one?
> >>>
> >>>
> >>>
> >>> Yeah, but to do that the code would now be something like:
> >>>
> >>>   vma_flags_t masked = flags;
> >>>
> >>>   /*
> >>>     * vma_flags_is_mm_managed() tests VMA_IO_BIT, which will be removed
> >>>    * in the next commit.
> >>>    */
> >>>   vma_flags_clear(&flags, VMA_IO_BIT);
> >>>   if (!vma_flags_is_mm_managed(masked)) {
> >>>           ...
> >>>   }
> >>>
> >>> Is that really worth it?
> >>>
> >>> I don't think there's really too much confusion intra-patch about that is 
> >>> there?
> >>
> >> I would do it as above (- the comment, as that is the next patch indeed) 
> >> and
> >> only remove the vma_flags_clear() in the next patch.
> >>
> >> But in any case, you should spell out that this is only temporary in the 
> >> patch
> >> description :)
> >
> > And then there's a 'masked' variable that is unused?
> >
> > You need to have two vma_flags_t variables to be able both clear VMA_IO_BIT
> > and use vma_flags_is_mm_managed().
> >
> > So the change would have to be
> >
> > +   vma_flags_t masked = *flags;
> > +
> > +   vma_flags_clear(&flags, VMA_IO_BIT);
> > +   if (!vma_flags_is_mm_managed(&masked)) {
> > +           ...
> > +   }
> >
> > Then:
> >
> > -   vma_flags_t masked = *flags;
> > -
> > -   vma_flags_clear(&flags, VMA_IO_BIT);
> > -   if (!vma_flags_is_mm_managed(&masked)) {
> > +   if (!vma_flags_is_mm_managed(flags)) {
> >             ...
> >     }
> >
> > Which doesn't really seem worth it for somebody who is confused between two
> > patches mid-series.
> >
> > But if you feel strongly I can make the change like that?
>
> Whatever you prefer. Most important thing for me was finding it in the next
> patch and being pleasantly surprised ;)

I'd rather not then!

It was always intended that way, this was all part of a careful dance to ensure
correct behaviour right up until the point where we enforce that VMA_IO_BIT is 
only set when appropriate.

I can update the commit message to reflect it.

--
Cheers, Lorenzo

Reply via email to