From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <dwg@au1.ibm.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
"cbe-oss-dev@ozlabs.org" <cbe-oss-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc: Introduce address space "slices"
Date: Wed, 21 Feb 2007 11:40:57 +1100 [thread overview]
Message-ID: <1172018457.18571.176.camel@localhost.localdomain> (raw)
In-Reply-To: <20070221002922.GG10231@localhost.localdomain>
On Wed, 2007-02-21 at 11:29 +1100, David Gibson wrote:
> On Wed, Feb 21, 2007 at 06:51:47AM +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2007-02-20 at 13:45 -0600, Adam Litke wrote:
> > > Your patch drops the pgoff check that prepare_hugepage_range used to
> > > check. The misaligned_offset test in libhugetlbfs identified the
> > > problem. The following patch (applied on top of yours) makes the
> > > problem go away. I am not necessarily suggesting it's the correct
> > > fix... just concisely describing the problem.
> >
> > Ok, I'll fold that into the patch. Ultimately, when I finally do the
> > generic changes, prepare_hugepage_range() will be going away. I will
> > either pass pgoff along to slice_g_u_a for it to validate the pgoff, or
> > I will let f_ops->mmap() be responsible of checking it. For SPEs, I do
> > the pgoff check there. Any reason tht wouldn't work for huge pages ?
>
> Err... there was. The trouble was the prepare() or
> get_unmapped_area() which could open new slices happens before the
> ->mmap() call, so we could have already converted segments,
> irreversibly, then have the mmap fail because of a bad alignment. Now
> that slice conversions can go both ways, that might not be a
> significant problem any more.
Ok. I'll start working on the generic g_u_a changes and will try to make
sure I get that right there. In the meantime, Adam's patch is good.
Ben.
prev parent reply other threads:[~2007-02-21 0:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-19 6:43 [PATCH] powerpc: Introduce address space "slices" Benjamin Herrenschmidt
2007-02-19 13:23 ` Jimi Xenidis
2007-02-19 19:42 ` Benjamin Herrenschmidt
2007-02-19 19:57 ` Jimi Xenidis
2007-02-19 15:33 ` Olof Johansson
2007-02-19 16:49 ` [Cbe-oss-dev] " Arnd Bergmann
2007-02-19 19:39 ` Benjamin Herrenschmidt
2007-02-19 20:15 ` Olof Johansson
2007-02-19 18:54 ` Adam Litke
2007-02-19 19:40 ` Benjamin Herrenschmidt
2007-02-19 20:35 ` Adam Litke
2007-02-19 20:47 ` Benjamin Herrenschmidt
2007-02-19 21:15 ` Adam Litke
2007-02-20 19:45 ` Adam Litke
2007-02-20 19:51 ` Benjamin Herrenschmidt
2007-02-20 20:07 ` Adam Litke
2007-02-21 0:29 ` David Gibson
2007-02-21 0:40 ` Benjamin Herrenschmidt [this message]
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=1172018457.18571.176.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=cbe-oss-dev@ozlabs.org \
--cc=dwg@au1.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.