[PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[Brian King]

It looks like most of the hugetlb code is doing the correct thing if
hugepages are not supported, but the mmap code is not. If we get into
the mmap code when hugepages are not supported, such as in an LPAR
which is running Active Memory Sharing, we can oops the kernel. This
patch fixes the oops being seen in this path.

ops: Kernel access of
bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: nfs(N) lockd(N) nfs_acl(N) sunrpc(N) ipv6(N) fuse(N) loop(N)
dm_mod(N) sg(N) ibmveth(N) sd_mod(N) crc_t10dif(N) ibmvscsic(N)
scsi_transport_srp(N) scsi_tgt(N) scsi_mod(N)
Supported: No
NIP: c000000000038d60 LR: c00000000003945c CTR: c0000000000393f0
REGS: c000000077e7b830 TRAP: 0300   Tainted: G          
(2.6.27.5-bz50170-2-ppc64)
MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 44000448  XER: 20000001
DAR: c000002000af90a8, DSISR: 0000000040000000
TASK = c00000007c1b8600[4019] 'hugemmap01' THREAD: c000000077e78000 CPU: 6
GPR00: 0000001fffffffe0 c000000077e7bab0 c0000000009a4e78 0000000000000000
GPR04: 0000000000010000 0000000000000001 00000000ffffffff 0000000000000001
GPR08: 0000000000000000 c000000000af90c8 0000000000000001 0000000000000000
GPR12: 000000000000003f c000000000a73880 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000010000
GPR20: 0000000000000000 0000000000000003 0000000000010000 0000000000000001
GPR24: 0000000000000003 0000000000000000 0000000000000001 ffffffffffffffb5
GPR28: c000000077ca2e80 0000000000000000 c00000000092af78 0000000000010000
NIP [c000000000038d60] .slice_get_unmapped_area+0x6c/0x4e0
LR [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80
Call Trace:
[c000000077e7bbc0] [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80
[c000000077e7bc30] [c000000000107e30] .get_unmapped_area+0x64/0xd8
[c000000077e7bcb0] [c00000000010b140] .do_mmap_pgoff+0x140/0x420
[c000000077e7bd80] [c00000000000bf5c] .sys_mmap+0xc4/0x140
[c000000077e7be30] [c0000000000086b4] syscall_exit+0x0/0x40
Instruction dump:
fac1ffb0 fae1ffb8 fb01ffc0 fb21ffc8 fb41ffd0 fb61ffd8 fb81ffe0 fbc1fff0
fbe1fff8 f821fef1 f8c10158 f8e10160 <7d49002e> f9010168 e92d01b0 eb4902b0

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---

 arch/powerpc/mm/hugetlbpage.c |    3 +++
 1 file changed, 3 insertions(+)

diff -puN arch/powerpc/mm/hugetlbpage.c~powerpc_hugepage_mmap_check arch/powerpc/mm/hugetlbpage.c
--- linux-2.6/arch/powerpc/mm/hugetlbpage.c~powerpc_hugepage_mmap_check	2008-12-03 16:08:40.000000000 -0600
+++ linux-2.6-bjking1/arch/powerpc/mm/hugetlbpage.c	2008-12-03 16:10:57.000000000 -0600
@@ -507,6 +507,9 @@ unsigned long hugetlb_get_unmapped_area(
 {
 	struct hstate *hstate = hstate_file(file);
 	int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));
+
+	if (!mmu_huge_psizes[mmu_psize])
+		return -EINVAL;
 	return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1, 0);
 }
 
_

Re: [PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[Paul Mackerras]

Brian King writes:

> It looks like most of the hugetlb code is doing the correct thing if
> hugepages are not supported, but the mmap code is not. If we get into
> the mmap code when hugepages are not supported, such as in an LPAR
> which is running Active Memory Sharing, we can oops the kernel. This
> patch fixes the oops being seen in this path.

Sounds like this is a regression since 2.6.27 - is it?  In any case, I
assume this needs to go to Linus for 2.6.28.  Do you agree?

Paul.

Re: [PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[Brian King]

Paul Mackerras wrote:
> Brian King writes:
> 
>> It looks like most of the hugetlb code is doing the correct thing if
>> hugepages are not supported, but the mmap code is not. If we get into
>> the mmap code when hugepages are not supported, such as in an LPAR
>> which is running Active Memory Sharing, we can oops the kernel. This
>> patch fixes the oops being seen in this path.
> 
> Sounds like this is a regression since 2.6.27 - is it?  In any case, I
> assume this needs to go to Linus for 2.6.28.  Do you agree?

This should go to Linus for 2.6.28

Thanks,

Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center

Re: [PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[Paul Mackerras]

Brian King writes:

> This should go to Linus for 2.6.28

OK, thanks, but is it a regression from 2.6.27?

(Serves me right for asking two questions in one email. :)

Paul.

Re: [PATCH 1/1] powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area

[Brian King]

Paul Mackerras wrote:
> Brian King writes:
> 
>> This should go to Linus for 2.6.28
> 
> OK, thanks, but is it a regression from 2.6.27?

Probably not. Its probably broken in 2.6.27 as well. 
Looking at the git history of arch/powerpc/mm/hugetlbpage.c,
it hasn't changed since 2.6.27 went out the door.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center