linux-kernel - Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1174558498.10836.30.camel@localhost.localdomain>
Date:	Thu, 22 Mar 2007 21:14:58 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Linux Memory Management <linux-mm@...ck.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area

> Great, this is long overdue for a cleanup.

Indeed... lots of redundant checks, dead code, etc...

> I haven't looked at all users of this, but does it make sense to switch
> to an API that takes an address range and modifies / filters it? Perhaps
> also filling in some other annotations (eg. alignment, topdown/bottom up).
> This way you could stack as many arch and driver callbacks as you need,
> while hopefully also having just a single generic allocator.
> 
> OTOH, that might end up being too inefficient or simply over engineered.
> Did you have any other thoughts about how to do this more generically?

I haven't quite managed to think about something that would fit
everybody...

The main problem is that the requirements are fairly arch specific in
nature... from page sizes, page attributes, to things like nommu who
want in some case to enfore virt=phys or to cache aliasing issues.

I think we can find a subset of "parameters" that represent the various
constraints... pgprot, page size, mostly. Then, we could stack up the
driver/fs g_u_a on top of the arch one, but it's not simple to do that
right. Who get's to pick an address first ? If the driver picks one but
the arch rejects it, the driver need a chance to pick another one ...

Or do we decide that only the arch knows, and thus the driver only
provides more detailed informations to the arch to pick something up...

That would be useful.. for example, some archs could really use knowing
at g_u_a time wether the mapping is to be cacheable or non cacheable.

I'm still thinking about it. I think my first patch set is a good step
to give some more flexibility to archs but is by no mean something to
settle on.

I need to simmer that more until my neurons manage to cough up some
nicer & generic abstraction/api to deal with that in a better way.

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/