linux-kernel - Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ba149c5b-e213-4047-b660-f44b1c8643b4@redhat.com>
Date: Wed, 11 Dec 2024 11:27:39 +0100
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Jann Horn <jannh@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA
 section

>>
> 
> 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