All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Adam Litke <agl@us.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 06:51:47 +1100	[thread overview]
Message-ID: <1172001107.18571.127.camel@localhost.localdomain> (raw)
In-Reply-To: <1172000736.22940.48.camel@localhost.localdomain>

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 ?

Ben.

> commit 95bcfa9c7b086de320cd9a1ff9c7281f7f16b15f
> Author: Adam Litke <agl@us.ibm.com>
> Date:   Tue Feb 20 11:44:46 2007 -0800
> 
>     Restore the pgoff check for prepare_hugepage_range()
> 
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index cbb8c52..f38ab78 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -349,6 +349,9 @@ int prepare_hugepage_range(unsigned long addr, unsigned long len, pgoff_t pgoff)
>  
>  	printk("prepare_hugepage_range(addr=0x%lx, len=0x%lx\n", addr, len);
>  
> +	if (pgoff & (~HPAGE_MASK >> PAGE_SHIFT))
> +		return -EINVAL;
> +
>  	/* This is only useful for MAP_FIXED so we turn it into that */
>  	gua_addr = slice_get_unmapped_area(addr, len, MAP_FIXED,
>  					   mmu_huge_psize, 1, 0);
> 

  reply	other threads:[~2007-02-20 19:51 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 [this message]
2007-02-20 20:07     ` Adam Litke
2007-02-21  0:29     ` David Gibson
2007-02-21  0:40       ` 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=1172001107.18571.127.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=agl@us.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 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.