From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] MAINTAINERS: rename MM to MM MISC, add missing files
Date: Wed, 23 Jul 2025 10:46:44 +0100 [thread overview]
Message-ID: <1feb8f0f-ff49-4a82-ae07-21a91918e5e7@lucifer.local> (raw)
In-Reply-To: <66daf9db-ce97-4345-886c-3f8ab111b4fc@suse.cz>
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@oracle.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@linux-foundation.org>
> > +M: David Hildenbrand <david@redhat.com>
> > +R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > +R: Liam R. Howlett <Liam.Howlett@oracle.com>
> > +R: Vlastimil Babka <vbabka@suse.cz>
> > +R: Mike Rapoport <rppt@kernel.org>
> > +R: Suren Baghdasaryan <surenb@google.com>
> > +R: Michal Hocko <mhocko@suse.com>
> > +L: linux-mm@kvack.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@linux-foundation.org>
> > M: Mike Rapoport <rppt@kernel.org>
> > --
> > 2.50.1
>
prev parent reply other threads:[~2025-07-23 9:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 19:27 Lorenzo Stoakes
2025-07-23 5:18 ` Mike Rapoport
2025-07-23 9:42 ` Vlastimil Babka
2025-07-23 9:46 ` Lorenzo Stoakes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1feb8f0f-ff49-4a82-ae07-21a91918e5e7@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox