Message-ID: <1feb8f0f-ff49-4a82-ae07-21a91918e5e7@lucifer.local>
Date: Wed, 23 Jul 2025 10:46:44 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, David Hildenbrand <david@...hat.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] MAINTAINERS: rename MM to MM MISC, add missing files

On Wed, Jul 23, 2025 at 11:42:09AM +0200, Vlastimil Babka wrote:
> On 7/22/25 21:27, Lorenzo Stoakes wrote:
> > To fit in with other sections within MAINTAINERS for memory management
> > files, rename the MEMORY MANAGEMENT section to MEMORY MANAGEMENT - MISC to
> > contain files that are not described by other sections.
> >
> > We also add missing files to MEMORY MANAGEMENT - MISC and MEMORY MANAGEMENT
> > - CORE sections.
> >
> > Move over appropriate files to the core section, and in both sections add
> > remaining missing files. At this point, with the other recent MAINTAINERS
> > changes, this should now mean that every memory management-related file has
> > a section and assigned maintainers/reviewers.
> >
> > For the time being, we maintain catch-all mm/ and tools/mm/ entries for MM
>
> This...
>
> > - MISC, though in future we may wish to remove these to make it obvious
> > when files don't have assigned entries.
> >
> > Finally, we copy across the maintainers/reviewers from MEMORY MANAGEMENT -
> > CORE to MEMORY MANAGEMENT - MISC, as it seems the two are sufficiently
> > related for this to be sensible.
>
> ... together with this means the pre-existing reviewers of CORE will now get
> CC'd on everything under mm/ - I'm not sure if this consequence was apparent
> and wanted, so pointing that out. Myself, as long as whole mm/ is there, I'd
> rather not be one of the R: purely for volume reasons. The misc files
> themselves would have been fine.

Hmm, I wrongly assumed it would act as a catch all for stuff not covered
elsewhere, but obviously you're right it will. OK will respin and put MM
section back just for this purpose.

>
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> > ---
> >
> > Andrew - apologies, but there will likely be some small conflicts here
> > given other MAINTAINERS patches move stuff from the MEMORY MANAGEMENT
> > section too.
> >
> > I kept patches separate in case one ends up having push-back we can still
> > have the rest putting missing files in place.
> >
> > Note that we also have [0] going through the slab tree, as it seemed a more
> > suitable place to do that change to minimise conflicts on that front.
> >
> > [0]: https://lore.kernel.org/all/20250722175901.152272-1-lorenzo.stoakes@oracle.com/
> >
> > REVIEWERS NOTES:
> >
> > This is based on discussions had in [1] both about this newly renamed
> > section and where David indicated he was open to maintainership of the misc
> > section.
> >
> > I am sending un-RFC'd as, while a lot of files being moved about, it seems
> > relatively safe to put these files in core/misc and we can move them around
> > later if necessary.
> >
> > Additionally, on the reviewers being added, these files are broadly files
> > that could have been placed in the 'core' section, so this is more or less
> > an administrative decision to split into two and so it seems reasonable to
> > maintain the same list of people.
> >
> > Apologies if this is overly presumptuous, the intent here is for us to
> > finally reach a point (with the other patches applied) where (as far as I
> > can tell) every memory management-related file should now have MAINTAINERS
> > entries.
> >
> > [1]: https://lore.kernel.org/all/20250616203844.566056-1-lorenzo.stoakes@oracle.com/
> >
> >  MAINTAINERS | 82 +++++++++++++++++++++++++++++++++++++----------------
> >  1 file changed, 57 insertions(+), 25 deletions(-)
> >
>
> <trim>
>
> > +MEMORY MANAGEMENT - MISC
> > +M:	Andrew Morton <akpm@...ux-foundation.org>
> > +M:	David Hildenbrand <david@...hat.com>
> > +R:	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> > +R:	Liam R. Howlett <Liam.Howlett@...cle.com>
> > +R:	Vlastimil Babka <vbabka@...e.cz>
> > +R:	Mike Rapoport <rppt@...nel.org>
> > +R:	Suren Baghdasaryan <surenb@...gle.com>
> > +R:	Michal Hocko <mhocko@...e.com>
> > +L:	linux-mm@...ck.org
> > +S:	Maintained
> > +W:	http://www.linux-mm.org
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > +F:	Documentation/admin-guide/mm/
> > +F:	Documentation/mm/
> > +F:	include/linux/memory-tiers.h
> > +F:	include/linux/mempolicy.h
> > +F:	include/linux/mempool.h
> > +F:	include/linux/memremap.h
>
> Weren't a bunch of these moved to other sections already?

Yeah this was a product of doing the patches separately.

Andrew sorted it out.

The respin should be ok for this, modulo stuff that's not merged yet (a couple
patches where I had to fixup).

>
> > +F:	include/linux/mmu_notifier.h
> > +F:	include/trace/events/ksm.h
> > +F:	mm/
> > +F:	mm/backing-dev.c
> > +F:	mm/cma.c
> > +F:	mm/cma_debug.c
> > +F:	mm/cma_sysfs.c
> > +F:	mm/dmapool.c
> > +F:	mm/dmapool_test.c
> > +F:	mm/early_ioremap.c
> > +F:	mm/fadvise.c
> > +F:	mm/io-mapping.c
> > +F:	mm/ioremap.c
> > +F:	mm/mapping_dirty_helpers.c
> > +F:	mm/memory-tiers.c
> > +F:	mm/mmu_notifier.c
> > +F:	mm/page_idle.c
> > +F:	mm/pgalloc-track.h
> > +F:	mm/process_vm_access.c
> > +F:	mm/ptdump.c
> > +F:	tools/mm/
> > +F:	tools/testing/selftests/mm/
> > +
> >  MEMORY MANAGEMENT - NUMA MEMBLOCKS AND NUMA EMULATION
> >  M:	Andrew Morton <akpm@...ux-foundation.org>
> >  M:	Mike Rapoport <rppt@...nel.org>
> > --
> > 2.50.1
>

Powered by blists - more mailing lists