Re: [PATCH 2/6] mm: add vma_desc_test_all() and use it

[Lorenzo Stoakes (Oracle)]

On Wed, Mar 25, 2026 at 07:30:54AM -0700, Andrew Morton wrote:
> On Wed, 25 Mar 2026 07:08:22 +0000 "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx> wrote:
>
> > On Tue, Mar 24, 2026 at 04:12:12PM -0700, Andrew Morton wrote:
> > > On Thu,  5 Mar 2026 10:50:15 +0000 "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx> wrote:
> > >
> > > > erofs and zonefs are using vma_desc_test_any() twice to check whether all
> > > > of VMA_SHARED_BIT and VMA_MAYWRITE_BIT are set, this is silly, so add
> > > > vma_desc_test_all() to test all flags and update erofs and zonefs to use
> > > > it.
> > > >
> > > > While we're here, update the helper function comments to be more
> > > > consistent.
> > > >
> > > > Also add the same to the VMA test headers.
> > >
> > > fwiw, we have no review tags on this one.
> >
> > Based on the discussion we had about this previously I was under the impression
> > if submitted by a maintainer that wasn't required?
>
> Well, it's a gray area.  Obviously it's better if people's stuff is
> checked by co-maintainers or by others.

OK that contradicts the previous conversation we had where you had to
convince me that this was ok (which I ended up agreeing with), rather than
being a grey area.

We had quite a long conversation about maintainers are in a trusted role so
a co-maintainer would have called it out it was wrong and etc.

But sure it'd be nice to get review, obviously I agree with that.

>
> I'm not inclined to make a fuss about it though (hence "fwiw").  Quite
> a lot of unreviewed maintainer-authored material ends up going upstream
> and I don't think that's causing much harm.

I think you need to be a lot clearer in communicating these things while
the process remains undocumented.

In this case for instance, I took that to mean that you required review,
the 'fwiw' doesn't really make it clear that this was optional, especially
given this patch is so trivial.

>
> In a lot of cases this is pretty much unavoidable because the patch
> comes from a sole maintainer (SJ, Sergey, Ulad, Liam come to mind).
> But when the author has co-maintainers, perhaps those people could step
> up.

Right.

>
> > I'll nag people, but I'm a bit surprised if this is why you haven't moved this
> > to mm-stable, given how trivially obviously correct this patch is.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/pc/devel-series
> shows my expected merging order.  It looks like this one will be in the
> next batch ->mm-stable.
>

I'll definietly need some decoding of that to understand where each batch
is?

To me it reads as a bunch of inscrutible #'s and file names...

Thanks, Lorenzo