[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101208005728.628795907@clark.site>
Date: Tue, 07 Dec 2010 16:57:30 -0800
From: Greg KH <gregkh@...e.de>
To: linux-kernel@...r.kernel.org, stable@...nel.org
Cc: stable-review@...nel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Michael Neuling <mikey@...ling.org>,
David Gibson <david@...son.dropbear.id.au>
Subject: [073/289] powerpc: Fix call to subpage_protection()
2.6.36-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Neuling <mikey@...ling.org>
commit 1c2c25c78740b2796c7c06640784cb6732fa4907 upstream.
In:
powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
commit d28513bc7f675d28b479db666d572e078ecf182d
Author: David Gibson <david@...son.dropbear.id.au>
subpage_protection() was changed to to take an mm rather a pgdir but it
didn't change calling site in hashpage_preload(). The change wasn't
noticed at compile time since hashpage_preload() used a void* as the
parameter to subpage_protection().
This is obviously wrong and can trigger the following crash when
CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_PPC_64K_PAGES
CONFIG_PPC_SUBPAGE_PROT are enabled.
Freeing unused kernel memory: 704k freed
Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6c49b7
Faulting instruction address: 0xc0000000000410f4
cpu 0x2: Vector: 300 (Data Access) at [c00000004233f590]
pc: c0000000000410f4: .hash_preload+0x258/0x338
lr: c000000000041054: .hash_preload+0x1b8/0x338
sp: c00000004233f810
msr: 8000000000009032
dar: 6b6b6b6b6b6c49b7
dsisr: 40000000
current = 0xc00000007e2c0070
paca = 0xc000000007fe0500
pid = 1, comm = init
enter ? for help
[c00000004233f810] c000000000041020 .hash_preload+0x184/0x338 (unreliable)
[c00000004233f8f0] c00000000003ed98 .update_mmu_cache+0xb0/0xd0
[c00000004233f990] c000000000157754 .__do_fault+0x48c/0x5dc
[c00000004233faa0] c000000000158fd0 .handle_mm_fault+0x508/0xa8c
[c00000004233fb90] c0000000006acdd4 .do_page_fault+0x428/0x6ac
[c00000004233fe30] c000000000005260 handle_page_fault+0x20/0x74
Reported-by: Jim Keniston <jkenisto@...ux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Signed-off-by: Michael Neuling <mikey@...ling.org>
cc: David Gibson <david@...son.dropbear.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
arch/powerpc/mm/hash_utils_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1122,7 +1122,7 @@ void hash_preload(struct mm_struct *mm,
else
#endif /* CONFIG_PPC_HAS_HASH_64K */
rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize,
- subpage_protection(pgdir, ea));
+ subpage_protection(mm, ea));
/* Dump some info in case of hash insertion failure, they should
* never happen so it is really useful to know if/when they do
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists