linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/12] Pass MAP_FIXED down to get_unmapped_area
@ 2007-04-12  2:20 Benjamin Herrenschmidt
  2007-04-12  2:20 ` [PATCH 1/12] get_unmapped_area handles MAP_FIXED on powerpc Benjamin Herrenschmidt
                   ` (12 more replies)
  0 siblings, 13 replies; 22+ messages in thread
From: Benjamin Herrenschmidt @ 2007-04-12  2:20 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Memory Management, linux-kernel

This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.

(Andrew, this is also candidate for 2.6.22 since I haven't had any real
objection, mostly suggestion for improving further, which I'll try to
do later, and I have further powerpc patches that rely on this).

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 filesystems/drivers
using that hook are doing so for arch specific purposes 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, I'm not 100% certain yet how,
possibly 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.

None of the above "issues" however are introduced by this patch, they are
already there, so I think the patch can go in.

Cheers,
Ben.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 22+ messages in thread
* [PATCH 0/12] Pass MAP_FIXED down to get_unmapped_area
@ 2007-04-24  5:33 Benjamin Herrenschmidt
  2007-04-24  5:33 ` [PATCH 8/12] get_unmapped_area handles MAP_FIXED on sparc64 Benjamin Herrenschmidt
  0 siblings, 1 reply; 22+ messages in thread
From: Benjamin Herrenschmidt @ 2007-04-24  5:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Linux Memory Management

This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.

(Andrew, this is also candidate for 2.6.22 since I haven't had any real
objection, mostly suggestion for improving further, which I'll try to
do later, and I have further powerpc patches that rely on this).

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 filesystems/drivers
using that hook are doing so for arch specific purposes 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, I'm not 100% certain yet how,
possibly 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.

None of the above "issues" however are introduced by this patch, they are
already there, so I think the patch can go ini for 2.6.22.

(Patch is against Linus current git, I'll give a go at -mm asap)

Cheers,
Ben.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 22+ messages in thread
end of thread, other threads:[~2007-04-24  5:33 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-12  2:20 [PATCH 0/12] Pass MAP_FIXED down to get_unmapped_area Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 1/12] get_unmapped_area handles MAP_FIXED on powerpc Benjamin Herrenschmidt
2007-04-12 22:27   ` William Lee Irwin III
2007-04-12  2:20 ` [PATCH 2/12] get_unmapped_area handles MAP_FIXED on alpha Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 3/12] get_unmapped_area handles MAP_FIXED on arm Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 4/12] get_unmapped_area handles MAP_FIXED on frv Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 5/12] get_unmapped_area handles MAP_FIXED on i386 Benjamin Herrenschmidt
2007-04-12 22:28   ` William Lee Irwin III
2007-04-12  2:20 ` [PATCH 6/12] get_unmapped_area handles MAP_FIXED on ia64 Benjamin Herrenschmidt
2007-04-12 22:29   ` William Lee Irwin III
2007-04-12  2:20 ` [PATCH 7/12] get_unmapped_area handles MAP_FIXED on parisc Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 8/12] get_unmapped_area handles MAP_FIXED on sparc64 Benjamin Herrenschmidt
2007-04-12 22:30   ` William Lee Irwin III
2007-04-12  2:20 ` [PATCH 9/12] get_unmapped_area handles MAP_FIXED on x86_64 Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 11/12] get_unmapped_area handles MAP_FIXED in generic code Benjamin Herrenschmidt
2007-04-12  2:20 ` [PATCH 10/12] get_unmapped_area handles MAP_FIXED in hugetlbfs Benjamin Herrenschmidt
2007-04-12 22:31   ` William Lee Irwin III
2007-04-12  2:20 ` [PATCH 12/12] get_unmapped_area doesn't need hugetlbfs hacks anymore Benjamin Herrenschmidt
2007-04-12 22:32   ` William Lee Irwin III
2007-04-12  2:56 ` [PATCH 0/12] Pass MAP_FIXED down to get_unmapped_area Wu, Bryan
2007-04-12  2:56   ` Benjamin Herrenschmidt
2007-04-24  5:33 Benjamin Herrenschmidt
2007-04-24  5:33 ` [PATCH 8/12] get_unmapped_area handles MAP_FIXED on sparc64 Benjamin Herrenschmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox