On 11/6/26 16:22, Lorenzo Stoakes (ARM) wrote: > 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?
I think it really depends. If changes are well standalone, I don't see why it couldn't just cleanly go through separate trees. Anything that is more involved (like the madvise change), there is not really a way around. Well, there is: stable topic branch and letting separate trees merge that ... > > 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? Maybe? We'll have to learn. Right now it immediately caused conflicts between mine and Andrew's tree. 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. I assume stable topic branches would fix that, but they are currently unfortunately not on the table ... :) > >> >> 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/ > >> >> [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 :( > > 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. -- Cheers, David
