On Mon, Aug 13, 2007 at 04:26:27PM -0700, [EMAIL PROTECTED] wrote:
>
> This is a note to let you know that we have just queued up the patch titled
>
> Subject: powerpc: Fix size check for hugetlbfs
>
> to the 2.6.22-stable tree. Its filename is
>
> powerpc-fix-size-check-for-hugetlbfs.patch
>
> A git repo of this tree can be found at
>
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
>
> >From [EMAIL PROTECTED] Mon Aug 13 16:17:09 2007
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 08 Aug 2007 15:44:15 +1000
> Subject: powerpc: Fix size check for hugetlbfs
> To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
> Cc: Paul Mackerras <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
>
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
Ok, I said I was going to look into a libhugetlbfs testcase for this.
Doesn't appear there's specifically a testcase for misaligned size -
I'll add one.
However, it seems the current kernel, on ppc64, gives a testcase
failure on 'misaligned_offset', because it's not failing a mapping
with a non-hugepage aligned file offset. I'm not sure (yet) if this
failure is also caused by the new slice code, but it seems a likely
candidate.
Still investigating...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
