linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 02 Mar 2007 22:32:56 +1100	[thread overview]
Message-ID: <20070302113317.0578FDE042@ozlabs.org> (raw)
In-Reply-To: <1172835163.743765.616483133775.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,

  parent reply	other threads:[~2007-03-02 11:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02 11:32 [PATCH 0/5] Support 64K pages mapping of SPE local stores on 4K kernel Benjamin Herrenschmidt
2007-03-02 11:32 ` [PATCH 1/5] powerpc: Fix spu SLB invalidations Benjamin Herrenschmidt
2007-03-02 11:32 ` Benjamin Herrenschmidt [this message]
2007-03-02 11:33 ` [PATCH 3/5] powerpc: Introduce address space "slices" Benjamin Herrenschmidt
2007-03-02 11:33 ` [PATCH 4/5] powerpc: Add ability to 4K kernel to hash in 64K pages Benjamin Herrenschmidt
2007-03-02 11:33 ` [PATCH 5/5] powerpc: spufs support for 64K LS mappings on 4K kernels Benjamin Herrenschmidt
2007-04-21 20:33 ` [PATCH 0/5] Support 64K pages mapping of SPE local stores on 4K kernel Arnd Bergmann
2007-04-21 22:44   ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2007-02-20  7:44 Benjamin Herrenschmidt
2007-02-20  7:44 ` [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=20070302113317.0578FDE042@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).