David, To avoid an infinite back-and-forth... I think you're stuck on the idea that we are sat in a VMA 'vacuum', perhaps because I put so much effort into separating out the VMA logic, for the purpose of being able to userland test it, it's almost given the wrong impression (I should perhaps have put less effort into this? :) But we have for quite some time now de facto been expected to maintain all aspects of mapping, remapping, etc. INCLUDING page table considerations. We are more or less de facto maintaining all that (modulo madvise.c - I grant you this is the odd one out). So you can imagine it's a bit frustrating, when that's the case, to be told in effect - no this isn't for you - right? For instance, as I said before, we have spent large parts of the 6.12 cycle dealing with practical concerns specifically around page table manipulation. Maintainership is more than setting up lei rules, obviously. One can set lei rules for anything. It means that our say has more impact, and it also means that we are (co-)responsible for the listed files, and that's acked rather than disregarded. So, again, I politely disagree with your assessment re: page tables. I think their manipulation under circumstances where you map/remap/mprotect/mlock is -inseparable- from memory mapping/VMA logic. Otherwise, what's the point right? My suggestion is that: a. we put everything in MEMORY MAPPING b. We drop mm/madvise.c from the list I'm more than happy to hear your suggestions however. But whatever your view won't change the de facto situation, it only makes it more difficult for us to do what is already expected of us... But I'd also like - given your strong push back - to remind you - this is not a coup :) we are simply co-maintainers with Andrew, we don't send a PR to Linus, the <2.5% of mm code this change represents would not be our sole domain... Thanks, Lorenzo
