On Fri, Nov 06, 2026 at 03:35:01PM +0100, David Hildenbrand (Arm) wrote: > I agree that this should be picked separately. For example, I will pick > everything that falls into my realm to reduce conflicts.
Hmm, generally tree-wide mechanical changes are the exception to that rule no? It's going to make the rest of the VMA flags/mmap_prepare conversion really quite difficult if I have to chase every single driver maintainer in the kernel (literally in both cases pretty much :). And sometimes there are dependencies which mean you really can't split it across trees unless you establish functionality in one cycle and callers in another, but that seems a little silly. I was thinking that once the VMA tree is separate I'd put mechanical changes like this through it. Is that not the way to go? > > 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. > > [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. 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? But there's no way for that change to only touch madvise() given the function decl/callers. -- Cheers, Lorenzo
