On Mon, Dec 09, 2024 at 10:16:21AM +0100, David Hildenbrand wrote: > On 06.12.24 20:16, Lorenzo Stoakes wrote: > > There are a number of means of interacting with VMA operations within mm, > > and we have on occasion not been made aware of impactful changes due to > > these sitting in different files, most recently in [0]. > > > > Correct this by bringing all VMA operations under the same section in > > MAINTAINERS. Additionally take the opportunity to combine MEMORY MAPPING > > with VMA as there needn't be two entries as they amount to the same thing. > > > > [0]:https://lore.kernel.org/linux-mm/CAG48ez0siYGB8GP5+Szgj2ovBZAkL6Zi4n6GUAjzzjFV9LTkRQ@xxxxxxxxxxxxxx/ > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > --- > > MAINTAINERS | 19 +++++++------------ > > 1 file changed, 7 insertions(+), 12 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 1e930c7a58b1..95db20c26f5f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -15060,18 +15060,6 @@ F: tools/mm/ > > F: tools/testing/selftests/mm/ > > N: include/linux/page[-_]* > > > > -MEMORY MAPPING > > -M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > -M: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > > -M: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > -R: Vlastimil Babka <vbabka@xxxxxxx> > > -R: Jann Horn <jannh@xxxxxxxxxx> > > -L: linux-mm@xxxxxxxxx > > -S: Maintained > > -W: http://www.linux-mm.org > > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > -F: mm/mmap.c > > - > > MEMORY TECHNOLOGY DEVICES (MTD) > > M: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > > M: Richard Weinberger <richard@xxxxxx> > > @@ -25028,6 +25016,13 @@ L: linux-mm@xxxxxxxxx > > S: Maintained > > W: https://www.linux-mm.org > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > +F: mm/madvise.c > > +F: mm/mlock.c > > +F: mm/mmap.c > > +F: mm/mprotect.c > > +F: mm/mremap.c > > +F: mm/mseal.c > > +F: mm/msync.c > > Not sure about mprotect.c, mlock.c and madvise.c, though. I'd claim that the > real "magic" they perform is in page table handling and not primarily VMA > handling (yes, both do VMA changes, but they are the "easy" part ;) ). And large parts of the VMA logic interface with page tables, see - the entire 6.12 cycle - around recent changes in mmap() MAP_FIXED - which... the VMA maintainers fixed :) And then there were the issues around VMA and mm locking relating to page table work which... oh right yeah we had to fix again... :>) I mean you can make this argument about probably all of these files (mremap has -tons- of page table-specific stuff), and then we get back to not being notified about key changes that interface with memory mapping/VMA which we end up having to deal with anyway. A lot of the reason we have 'magic' in these files anyway is because we don't have a decent generic page table handler. Not sure I'd actually use the word 'magic' for that though. I am planning to make significant changes to mprotect/mlock soon, which have some terribly duplicated horrible handling logic, and both are key considerations in VMA logic as a whole. Anyway, as far as I'm concerned page table manipulation after the point of faulting is completely within the purvue of VMA manipulation and a side product of it. However, can concede mm/madvise.c if you feel strongly about that as that's a bit blurry, but of course contains a whole bunch of VMA and... page table manipulation :) I mean it still to me seems very pertinent. > > They have much more in common with memory.c, which I wouldn't want to see in > here either. Hm. No, memory.c is really dedicated to fault handling. This is really different from manipulating page tables in specific cases in my opinion. > > -- > Cheers, > > David / dhildenb > In case you are concerned about how much code this actually spans, it's ~6ksloc out of ~127ksloc, with roughly half of that in mm/vma.c...
