[lkml]   [2007]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area
    !!! 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-22 07:05    [W:0.019 / U:31.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site