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

Message-ID: <CAC_TJvdZxQ0-O3Y1bzH0-XdjQYuJPkkpn-umVan--Z6As-tSow@mail.gmail.com>
Date: Fri, 13 Dec 2024 12:08:18 -0500
From: Kalesh Singh <kaleshsingh@...gle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	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()

On Fri, Dec 13, 2024 at 11:45 AM 'Liam R. Howlett' via kernel-team
<kernel-team@...roid.com> wrote:
>
> * 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.
>

I build-tested most of these except (csky and loongarch) and ran
android runtime (ART) tests on arm64 and x86. I can try to spin up a
few of the others and will add it to the description.

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

Initially I think we can remove the mmap hint portion of the logic;
and follow up with removing arch_get_unmapped_area[_topdown](). Some
of those may not make sense to consolidate e.g. powerpc's
slice_get_unmapped_area() which doesn't share much in common with the
rest.

Thanks,
Kalesh

>
> Thanks,
> Liam
>
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@...roid.com.
>