linux-kernel - Re: [PATCH 0/5] mm/vma: make more mmap logic userland testable

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: <e15d144b-e32f-4e2f-8157-9b1320876ea4@lucifer.local>
Date: Mon, 9 Dec 2024 10:35:47 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Wei Yang <richard.weiyang@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] mm/vma: make more mmap logic userland testable

On Fri, Dec 06, 2024 at 12:30:54AM +0000, Wei Yang wrote:
> On Thu, Dec 05, 2024 at 07:03:08AM +0000, Lorenzo Stoakes wrote:
> >On Wed, Dec 04, 2024 at 11:56:32PM +0000, Wei Yang wrote:
> >> On Tue, Dec 03, 2024 at 06:05:07PM +0000, Lorenzo Stoakes wrote:
> >> >This series carries on the work the work started in previous series and
> >>                         ^^^      ^^^
> >>
> >> Duplicated?
> >
> >Thanks yes, but trivial enough that I'm not sure it's worth a
> >correction. Will fix if need to respin.
> >
> >>
> >> >continued in commit 52956b0d7fb9 ("mm: isolate mmap internal logic to
> >> >mm/vma.c"), moving the remainder of memory mapping implementation details
> >> >logic into mm/vma.c allowing the bulk of the mapping logic to be unit
> >> >tested.
> >> >
> >> >It is highly useful to do so, as this means we can both fundamentally test
> >> >this core logic, and introduce regression tests to ensure any issues
> >> >previously resolved do not recur.
> >> >
> >> >Vitally, this includes the do_brk_flags() function, meaning we have both
> >> >core means of userland mapping memory now testable.
> >> >
> >> >Performance testing was performed after this change given the brk() system
> >> >call's sensitivity to change, and no performance regression was observed.
> >>
> >> May I ask what performance test is done?
> >
> >mmtests brk1, brk2 (will-it-scale)
>
> The one from here ?
>
> https://github.com/gormanm/mmtests

Yes

>
> >
> >You'd not really expect an impact based on relocation of this code, but
> >with brk it's always worth checking...
> >
>
> Yes, I am trying to know usually what perform test we would use.

Mel's tests also pull in from the will-it-scale project [0], which these brk
tests I'm referring to originate. The mmtest logic just performs some
statistical analysis and comparisons etc. across a number of different test
sources.

[0]:https://github.com/antonblanchard/will-it-scale

>
> >>
> >>
> >> --
> >> Wei Yang
> >> Help you, Help me
>
> --
> Wei Yang
> Help you, Help me