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]
Date:	Thu, 05 Apr 2007 09:20:33 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Howells <dhowells@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arch@...r.kernel.org,
	Linux Memory Management <linux-mm@...ck.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/14] Pass MAP_FIXED down to get_unmapped_area

On Wed, 2007-04-04 at 11:31 +0100, David Howells wrote:
> Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> 
> > This serie of patches moves the logic to handle MAP_FIXED down to the
> > various arch/driver get_unmapped_area() implementations, and then changes
> > the generic code to always call them. The hugetlbfs hacks then disappear
> > from the generic code.
> 
> This sounds like get_unmapped_area() is now doing more than it says on the
> tin.  As I understand it, it's to be called to locate an unmapped area when
> one wasn't specified by MAP_FIXED, and so shouldn't be called if MAP_FIXED is
> set.

Well... that was the initial implementation. But that doesn't quite deal
well with various issues like page size constraints like the segment
constraints on powerpc or other hugetlbfs realted issues, and the
aliasing problems on architectures with virtually caches...

Just look at how many architectures already have special case for
MAP_FIXED in their arch_get_unmapped_area ! It was never called so far
though, my patch makes it being called.

I agree it's probably not the best interface, but I'm still trying to
figure out something that would be nicer as a "second step", as I don't
want to do too much in one set of patches. This serie allows me to hook
in my SPE 64K page thingy, to cleanup & improve a bit my hugetlb
handling, and possibly fixes some of those aliasing issues on
architectures with virtual caches...

> Admittedly, on NOMMU, it's also used to find the location of quasi-memory
> devices such as framebuffers and ramfs files, but that's not a great deviation
> from the original intent.
> 
> Perhaps a change of name is in order for the function?

I'm not sure. "get" can mean "obtain" :-) The way it's currently
implemented for me on powerpc works fine that way, I don't need an
"unget".

> > Since I need to do some special 64K pages mappings for SPEs on cell, I need
> > to work around the first problem at least. I have further patches thus
> > implementing a "slices" layer that handles multiple page sizes through
> > slices of the address space for use by hugetlbfs, the SPE code, and possibly
> > others, but it requires that serie of patches first/
> 
> That makes it sound like there should be an "unget" too for when an error
> occurs between ->get_unmapped_area() being called and ->mmap() returning
> successfully.

I don't need it because I can flip the page size of the segment back if
it has no VMA in it on the next get_unmapped_area(). Again, I'd like to
come up with a better interface, and I might post something in that
direction next week, but I beleive those patches (+/- bug fixes) are a
good first step in the right direction. I also need to find a proper way
to solve the mremap problem as it's bogus as it is already with things
like hugetlbfs on powerpc at least. 

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ