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] [day] [month] [year] [list]

Message-ID: <e74f5696-7a95-4e93-b11c-c70079a6dd7f@lucifer.local>
Date: Wed, 11 Dec 2024 10:44:56 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.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

On Wed, Dec 11, 2024 at 11:27:39AM +0100, David Hildenbrand wrote:
> > >
> >
> > 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.

I think any definition will end up a little fuzzy. For me it's anything
relating to mapping memory and changing its attributes.

I quite like the 'anything that affects /proc/self/maps output' but of
course you can find exceptions to all these rules...

I think we just have to live with a bit of vagueness unfortunately.

But we can definitely do future work on moving things around to make this
clearer. I think there's more benefit to moving stuff around than some
strict adherence to a sense of X belongs in file y etc., because it also
encourages de-duplication and prevents unrelated logic sitting in a file
where it might be neglected.

Anyway one for the new year :)

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

I sort of feel it's ok to have that in mempolicy.c with other NUMA related
syscalls, it's still grouped by syscall pretty much there.

We do have weirdness with random things that don't seem to belong sitting
in random files though, vma_migratable() being there is weird for instance.

Anyway, one thing at a time :)

>
> --
> Cheers,
>
> David / dhildenb
>