From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: <linuxppc-dev@ozlabs.org>, <cbe-oss-dev@ozlabs.org>
Cc: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Subject: [PATCH 2/5] This is a hack to get_unmapped_area to make the SPE 64K code work.
Date: Tue, 20 Feb 2007 18:44:13 +1100	[thread overview]
Message-ID: <20070220074432.D85DADDD0E@ozlabs.org> (raw)
In-Reply-To: <1171957452.861958.803775545202.qpush@grosgo>
(Though it might prove to not have nasty side effects ...)
The basic idea is that if the filesystem's get_unmapped_area was used,
we skip the hugepage check. That assumes that the only filesytems that
provide a g_u_a callback are either hugetlbfs itself, or filesystems
that have arch specific code that "knows" already not to collide with
hugetlbfs.
A proper fix will be done later, basically by removing the hugetlbfs
hacks completely from get_unmapped_area and calling down to the mm
and/or the filesytem g_u_a implementations for MAX_FIXED as well.
(Note that this will still rely on the fact that filesytems that
provide a g_u_a "know" how to return areas that don't collide with
hugetlbfs, thus the base assumption is the same as this hack)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
 mm/mmap.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-cell/mm/mmap.c
===================================================================
--- linux-cell.orig/mm/mmap.c	2007-02-20 18:09:12.000000000 +1100
+++ linux-cell/mm/mmap.c	2007-02-20 18:10:08.000000000 +1100
@@ -1357,14 +1357,17 @@ unsigned long
 get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
 		unsigned long pgoff, unsigned long flags)
 {
-	unsigned long ret;
+	unsigned long ret = 0;
+	int fs_area = 0;
 
 	if (!(flags & MAP_FIXED)) {
 		unsigned long (*get_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
 
 		get_area = current->mm->get_unmapped_area;
-		if (file && file->f_op && file->f_op->get_unmapped_area)
+		if (file && file->f_op && file->f_op->get_unmapped_area) {
 			get_area = file->f_op->get_unmapped_area;
+			fs_area = 1;
+		}
 		addr = get_area(file, addr, len, pgoff, flags);
 		if (IS_ERR_VALUE(addr))
 			return addr;
@@ -1380,7 +1383,7 @@ get_unmapped_area(struct file *file, uns
 		 * can be made suitable for hugepages.
 		 */
 		ret = prepare_hugepage_range(addr, len, pgoff);
-	} else {
+	} else if (!fs_area) {
 		/*
 		 * Ensure that a normal request is not falling in a
 		 * reserved hugepage range.  For some archs like IA-64,
next prev parent reply	other threads:[~2007-02-20  7:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20  7:44 [PATCH 0/5] Support 64K pages mapping of SPE local stores on 4K kernel Benjamin Herrenschmidt
2007-02-20  7:44 ` [PATCH 1/5] powerpc: Fix spu SLB invalidations Benjamin Herrenschmidt
2007-02-20  7:44 ` Benjamin Herrenschmidt [this message]
2007-02-20  7:44 ` [PATCH 3/5] powerpc: Introduce address space "slices" Benjamin Herrenschmidt
2007-03-01  6:11   ` [PATCH] Allow spufs to build as a module with slices enabled Michael Ellerman
2007-03-02  2:15     ` [Cbe-oss-dev] " Christoph Hellwig
2007-03-02  4:10       ` Michael Ellerman
2007-02-20  7:44 ` [PATCH 4/5] powerpc: Add ability to 4K kernel to hash in 64K pages Benjamin Herrenschmidt
2007-02-20  7:44 ` [PATCH 5/5] powerpc: spufs support for 64K LS mappings on 4K kernels Benjamin Herrenschmidt
2007-03-01  7:29 ` [PATCH 0/5] Support 64K pages mapping of SPE local stores on 4K kernel Michael Ellerman
  -- strict thread matches above, loose matches on Subject: below --
2007-03-02 11:32 Benjamin Herrenschmidt
2007-03-02 11:32 ` [PATCH 2/5] This is a hack to get_unmapped_area to make the SPE 64K code work 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=20070220074432.D85DADDD0E@ozlabs.org \
    --to=benh@kernel.crashing.org \
    --cc=arnd.bergmann@de.ibm.com \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
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).