Re: [PATCH 00/13] mm: continue vma_flags_t conversion

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

I think we're slightly talking across purposes, so to be clear - I am totally
fine with you taking any of this through your tree or whatever works for you and
Andrew to avoid merge pain :)

I was just talking more generally about how to merge series that touch a lot of
subsystems and maintainers-who-may-never-reply, etc.

These are the edge cases that make things... fun :)

Anyway, I guess easiest resolution here is for you to take the bits that belong
to your trees and Andrew takes the bits that belong elsewhere?

I don't think anything here has an inter-dependency.


On Sat, Nov 07, 2026 at 08:26:29PM +0100, David Hildenbrand (Arm) wrote:
[ ... ]
>
> Because of [PATCH 05/13] mm: convert THP VMA flag tests to use vma_flags_t which
> is THP-only, and feels like it could go straight through one of my trees,
> avoiding conflicts with Andrew's tree. But maybe there is more to it that I am
> missing.

Sorry about that! Please take that through your tree.

>
> I assume stable topic branches would fix that, but they are currently
> unfortunately not on the table ... :)

I guess we need everybody-on-git for this!

I guess when Liam and & I have the VMA tree we can do that at least for stuff
that goes there :)

>
> >
> >>
> >> Ideally, patches really only touch one component.
> >
> > Right, but sometimes functions are declared in one place and called in
> > others. It is impossible to change the signature of one without also touching
> > the others.
>
> Yes. Something like that is unavoidable. Or if you need new APIs/

Yes.

>
> >
> >>
> >> [PATCH 07/13] mm/madvise: convert madvise_vma_behavior() to use vma_flags_t
> >>
> >> is all over the place :)
> >
> > It's not really all over the place, it's converting vm_flags_t to
> > vma_flags_t across madvise.c, which involves changing a few function
> > signatures, whose callers must be updated.
>
> Ah, yeah. What on earth does arch/powerpc/kvm/book3s_hv_uvmem.c do with madvise :(

Yeah it's quite worrying that... :)

>
> >
> > I could split it up into 3 patches where 1 does internal-only, one changes 1
> > function, and the next changes another, if that works?
>
> No, these things really have to go in as one unit, no need to split that up.

Thanks, yeah, it's a pain I know but eventually 'one fine day' (probably in
2028) everything will be converted to vma_flags_t/mmap_prepare and we won't have
to think about this :P

--
Cheers, Lorenzo