linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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



  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