linux-kernel - Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap

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: <x2y7rewvmri25wj72qaeuunqqsqj7pqcliahoxkprcbfxg5owv@icvnojkhrdch>
Date: Fri, 13 Dec 2024 11:45:32 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Kalesh Singh <kaleshsingh@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>, vbabka@...e.cz,
        yang@...amperecomputing.com, riel@...riel.com, david@...hat.com,
        minchan@...nel.org, jyescas@...gle.com, linux@...linux.org.uk,
        tsbogend@...ha.franken.de, James.Bottomley@...senpartnership.com,
        ysato@...rs.sourceforge.jp, dalias@...c.org,
        glaubitz@...sik.fu-berlin.de, davem@...emloft.net, andreas@...sler.com,
        tglx@...utronix.de, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, chris@...kel.net, jcmvbkbc@...il.com,
        bhelgaas@...gle.com, jason.andryuk@....com, leitao@...ian.org,
        linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-snps-arc@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
        loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-mm@...ck.org,
        kernel-team@...roid.com, android-mm@...gle.com,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

* Lorenzo Stoakes <lorenzo.stoakes@...cle.com> [241213 10:16]:
> On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote:
> > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes
> > <lorenzo.stoakes@...cle.com> wrote:

...

> >
> > On the technical side, Liam is right that the copy-pasted arch code
> > has inconsistencies (missing checks, order of checks, ...). I agree
> > there’s room for further consolidation. I’ll take another stab at it
> > and resend it as an RFC with an updated cover letter, as Lorenzo and
> > others suggested.

Thanks.  Can you please include what platforms you have tested in your
cover letter (and level of testing - booting, running something, etc).

If you have not tested them, then it might be worth it to have it as an
RFC to point this out - at least initially.  Some of these are very
difficult to set up for testing, but it is also possible that you did
that and the maintainers/people who usually test these things will
assume it's fine if you don't spell out what's going on.

> 
> The most useful thing here as well to help us understand would be to write
> more in the cover letter to expand on what it is you ultimately what to
> achieve here - it seems like an extension on the existing THP work on a
> per-arch basis (I may be wrong)? So adding more detail would be super
> useful here! :)
> 
> We do hope to avoid arch hooks if at all possible explicitly for the reason
> that they can be applied at unfortunate times in terms of locking/whether
> the objects in question are fully/partially instantiated, VMA visibility
> etc. etc. based on having had issues in these areas before.
> 
> Also if a hook means 'anything' can happen at a certain point, it means we
> can't make any assumptions about what has/hasn't and have to account for
> anything which seriously complicates things.
> 
> Ideally we'd find a means to achieve the same thing while also exposing us
> as little as possible to what may be mutated.


Yes, I'm not sure of what your plans are, but I would like to see all of
these custom functions removed, if at all possible.

Thanks,
Liam