From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Jann Horn <jannh@google.com>, Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA section
Date: Wed, 11 Dec 2024 11:27:39 +0100 [thread overview]
Message-ID: <ba149c5b-e213-4047-b660-f44b1c8643b4@redhat.com> (raw)
In-Reply-To: <bd0ebc49-e5ce-4cb2-a7a1-14e864c5888e@lucifer.local>
>>
>
> OK so I think we're (probably?) now agreed, I will submit a patch shortly
> that:
>
> a. puts everything in MEMORY MAPPING
> b. Drops mm/madvise.c, mm/msync.c from the list
> c. I commit to moving things out of the various files that truly belongs
> elsewhere
> > I mean there's stuff that's weirdly used for page table moving in
mremap.c
> that should probably live in memory.c as well for instance.
Yes, and hopefully we can clearly frame what MEMORY MAPPING is supposed
to contain. I tried to tackle it with "/proc/self/maps output", but
that's probably not the complete story.
For example, maybe mbind() should, for example, at some point be
separated out into into mbind.c (making use of mempolicy.c
functionality?) and covered there as well? I really don't know, maybe
it's not one of the mmap/munmap/mprotect/mremap/mseal/mlock gang after all.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-12-11 10:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 19:16 Lorenzo Stoakes
2024-12-06 19:35 ` Liam R. Howlett
2024-12-09 9:16 ` David Hildenbrand
2024-12-09 10:06 ` Lorenzo Stoakes
2024-12-09 14:09 ` David Hildenbrand
2024-12-09 14:28 ` Lorenzo Stoakes
2024-12-09 14:56 ` David Hildenbrand
2024-12-09 15:04 ` Lorenzo Stoakes
2024-12-09 13:25 ` Vlastimil Babka
2024-12-09 14:00 ` David Hildenbrand
2024-12-09 14:11 ` Lorenzo Stoakes
2024-12-09 14:25 ` David Hildenbrand
2024-12-09 14:38 ` Jann Horn
2024-12-09 14:44 ` David Hildenbrand
2024-12-09 14:45 ` Lorenzo Stoakes
2024-12-09 15:03 ` David Hildenbrand
2024-12-09 15:16 ` Lorenzo Stoakes
2024-12-09 22:02 ` David Hildenbrand
2024-12-10 9:51 ` Lorenzo Stoakes
2024-12-10 16:59 ` David Hildenbrand
2024-12-11 9:35 ` Lorenzo Stoakes
2024-12-11 10:27 ` David Hildenbrand [this message]
2024-12-11 10:44 ` Lorenzo Stoakes
2024-12-10 16:06 ` Liam R. Howlett
2024-12-09 14:32 ` Lorenzo Stoakes
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=ba149c5b-e213-4047-b660-f44b1c8643b4@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.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