LKML Archive on
help / color / mirror / Atom feed
From: Nick Piggin <>
To: Benjamin Herrenschmidt <>
Cc: Linux Memory Management <>,
Subject: Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area
Date: Thu, 22 Mar 2007 18:29:25 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1174543217.531981.572863804039.qpush@grosgo>

Benjamin Herrenschmidt wrote:
> !!! This is a first cut, and there are still cleanups to be done in various
> areas touched by that code. I also haven't done descriptions yet for the
> individual patches.
> The current get_unmapped_area code calls the f_ops->get_unmapped_area or
> the arch one (via the mm) only when MAP_FIXED is not passed. That makes
> it impossible for archs to impose proper constraints on regions of the
> virtual address space. To work around that, get_unmapped_area() then
> calls some hugetlbfs specific hacks.
> This cause several problems, among others:
>  - It makes it impossible for a driver or filesystem to do the same thing
> that hugetlbfs does (for example, to allow a driver to use larger page
> sizes to map external hardware) if that requires applying a constraint
> on the addresses (constraining that mapping in certain regions and other
> mappings out of those regions).
>  - Some archs like arm, mips, sparc, sparc64, sh and sh64 already want
> MAP_FIXED to be passed down in order to deal with aliasing issues.
> The code is there to handle it... but is never called.
> 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.
> 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/
> There is still a potential (but not practical) issue due to the fact that
> filesystems/drivers implemeting g_u_a will effectively bypass all arch
> checks. This is not an issue in practice as the only users of those are
> actually doing so are doing it using arch hooks in the first place.
> There is also a problem with mremap that will completely bypass all arch
> checks. I'll try to address that separately mostly by making it not work
> when the vma has a file whose f_ops has a get_unmapped_area callback,
> and by making it use is_hugepage_only_range() before expanding into a
> new area.
> Also, I want to turn is_hugepage_only_range() into a more generic
> is_normal_page_range() as that's really what it will end up meaning
> when used in stack grow, brk grow and mremap.

Great, this is long overdue for a cleanup.

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?

SUSE Labs, Novell Inc.
Send instant messages to your online friends 

  parent reply	other threads:[~2007-03-22  7:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-22  6:00 Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 1/15] get_unmapped_area handles MAP_FIXED on powerpc Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 2/15] get_unmapped_area handles MAP_FIXED on alpha Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 3/15] get_unmapped_area handles MAP_FIXED on arm Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 4/15] get_unmapped_area handles MAP_FIXED on frv Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 5/15] get_unmapped_area handles MAP_FIXED on i386 Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 6/15] get_unmapped_area handles MAP_FIXED on ia64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 7/15] get_unmapped_area handles MAP_FIXED on parisc Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 8/15] get_unmapped_area handles MAP_FIXED on sparc64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 9/15] get_unmapped_area handles MAP_FIXED on x86_64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 10/15] get_unmapped_area handles MAP_FIXED in hugetlbfs Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 11/15] get_unmapped_area handles MAP_FIXED on ramfs (nommu) Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 12/15] get_unmapped_area handles MAP_FIXED in ffb DRM Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 13/15] get_unmapped_area handles MAP_FIXED in /dev/mem (nommu) Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 15/15] get_unmapped_area doesn't need hugetlbfs hacks anymore Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 14/15] get_unmapped_area handles MAP_FIXED in generic code Benjamin Herrenschmidt
2007-03-22  7:29 ` Nick Piggin [this message]
2007-03-22 10:14   ` [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area Benjamin Herrenschmidt
2007-03-22 10:29     ` Nick Piggin
2007-03-22 10:38       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).