* [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 @ 2010-04-28 7:22 Benjamin Herrenschmidt 2010-04-28 19:15 ` Xianghua Xiao 0 siblings, 1 reply; 9+ messages in thread From: Benjamin Herrenschmidt @ 2010-04-28 7:22 UTC (permalink / raw) To: linuxppc-dev So we tried to speed things up a bit using flush_hash_pages() directly but that falls over on 603 of course meaning we fail to flush the TLB properly and we may even end up having it corrupt memory randomly by accessing a hash table that doesn't exist. This removes the "optimization" by always going through flush_tlb_page() for now at least. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- Somebody with a 603 or e300 core based FSL SoC to try this out for me ? It's obviously completely untested :-) Cheers, Ben. diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index b9243e7..95774b4 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -385,11 +385,7 @@ static int __change_page_attr(struct page *page, pgprot_t prot) return -EINVAL; __set_pte_at(&init_mm, address, kpte, mk_pte(page, prot), 0); wmb(); -#ifdef CONFIG_PPC_STD_MMU - flush_hash_pages(0, address, pmd_val(*kpmd), 1); -#else flush_tlb_page(NULL, address); -#endif pte_unmap(kpte); return 0; ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-04-28 7:22 [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 Benjamin Herrenschmidt @ 2010-04-28 19:15 ` Xianghua Xiao 2010-04-28 19:46 ` Kim Phillips 2010-04-28 22:29 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 9+ messages in thread From: Xianghua Xiao @ 2010-04-28 19:15 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On Wed, Apr 28, 2010 at 2:22 AM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > So we tried to speed things up a bit using flush_hash_pages() directly > but that falls over on 603 of course meaning we fail to flush the TLB > properly and we may even end up having it corrupt memory randomly by > accessing a hash table that doesn't exist. > > This removes the "optimization" by always going through flush_tlb_page() > for now at least. > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > --- > > Somebody with a 603 or e300 core based FSL SoC to try this out for me ? > > It's obviously completely untested :-) > > Cheers, > Ben. > > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index b9243e7..95774b4 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -385,11 +385,7 @@ static int __change_page_attr(struct page *page, pgp= rot_t prot) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL; > =C2=A0 =C2=A0 =C2=A0 =C2=A0__set_pte_at(&init_mm, address, kpte, mk_pte(p= age, prot), 0); > =C2=A0 =C2=A0 =C2=A0 =C2=A0wmb(); > -#ifdef CONFIG_PPC_STD_MMU > - =C2=A0 =C2=A0 =C2=A0 flush_hash_pages(0, address, pmd_val(*kpmd), 1); > -#else > =C2=A0 =C2=A0 =C2=A0 =C2=A0flush_tlb_page(NULL, address); > -#endif > =C2=A0 =C2=A0 =C2=A0 =C2=A0pte_unmap(kpte); > > =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0; > > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > This change works me on a 834x(e300) platform, tested with lmbench and a production-ready application with 2.6.33.3. Xianghua ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-04-28 19:15 ` Xianghua Xiao @ 2010-04-28 19:46 ` Kim Phillips 2010-04-28 22:29 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 9+ messages in thread From: Kim Phillips @ 2010-04-28 19:46 UTC (permalink / raw) To: Xianghua Xiao; +Cc: linuxppc-dev On Wed, 28 Apr 2010 14:15:50 -0500 Xianghua Xiao <xiaoxianghua@gmail.com> wrote: > On Wed, Apr 28, 2010 at 2:22 AM, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > So we tried to speed things up a bit using flush_hash_pages() directly > > but that falls over on 603 of course meaning we fail to flush the TLB > > properly and we may even end up having it corrupt memory randomly by > > accessing a hash table that doesn't exist. > > > > This removes the "optimization" by always going through flush_tlb_page() > > for now at least. > > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > --- > > Somebody with a 603 or e300 core based FSL SoC to try this out for me ? > > > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. moi aussi, Ben: booted this on an 8377 and started a kernel build. It seems to be progressing normally, I'm just not going to wait for it to complete before hitting send :). Kim ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-04-28 19:15 ` Xianghua Xiao 2010-04-28 19:46 ` Kim Phillips @ 2010-04-28 22:29 ` Benjamin Herrenschmidt 2010-05-02 10:27 ` Maindoor 1 sibling, 1 reply; 9+ messages in thread From: Benjamin Herrenschmidt @ 2010-04-28 22:29 UTC (permalink / raw) To: Xianghua Xiao; +Cc: linuxppc-dev On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that is to - get_free_pages a page - read from it - free it - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-04-28 22:29 ` Benjamin Herrenschmidt @ 2010-05-02 10:27 ` Maindoor 2010-05-03 14:19 ` Xianghua Xiao 0 siblings, 1 reply; 9+ messages in thread From: Maindoor @ 2010-05-02 10:27 UTC (permalink / raw) To: Xianghua Xiao, Benjamin Herrenschmidt; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1031 bytes --] Any updates on this ? I need something similar. Thanks, Maindoor. --- On Thu, 4/29/10, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" <xiaoxianghua@gmail.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Thursday, April 29, 2010, 3:59 AM On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that is to - get_free_pages a page - read from it - free it - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev [-- Attachment #2: Type: text/html, Size: 1649 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-05-02 10:27 ` Maindoor @ 2010-05-03 14:19 ` Xianghua Xiao 2010-05-04 5:13 ` Benjamin Herrenschmidt 2010-05-06 8:23 ` Maindoor 0 siblings, 2 replies; 9+ messages in thread From: Xianghua Xiao @ 2010-05-03 14:19 UTC (permalink / raw) To: Maindoor; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 6681 bytes --] On Sun, May 2, 2010 at 5:27 AM, Maindoor <sanjeevfiles@yahoo.com> wrote: > Any updates on this ? I need something similar. > > Thanks, > Maindoor. > > --- On *Thu, 4/29/10, Benjamin Herrenschmidt <benh@kernel.crashing.org>*wrote: > > > From: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 > To: "Xianghua Xiao" <xiaoxianghua@gmail.com> > Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> > Date: Thursday, April 29, 2010, 3:59 AM > > On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > > This change works me on a 834x(e300) platform, tested with lmbench and > > a production-ready application with 2.6.33.3. > > But have you tested that DEBUG_PAGEALLOC actually works ? :-) > > A way to do that is to > > - get_free_pages a page > - read from it > - free it > - write to it > > It should oops on the write, and I suspect that without my patch it > doesn't. > > Cheers, > Ben. > > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org<http://mc/compose?to=Linuxppc-dev@lists.ozlabs.org> > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > Ok here is the test result I did this morning, in short with/without Ben's patch it will oops if you write to a freed page. 1. With DEBUG_PAGEALLOC on, after applied Ben's patch and wrote to a freed page, it will oops: -------------------------------------- Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce33c000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: cf231e30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 24000422 XER: 20000000 DAR: ce33c000, DSISR: 22000000 TASK = ce312e10[1395] 'insmod' THREAD: cf230000 GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bfd2ff80 c043d388 00000000 d004d000 c0480000 cf230000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [cf231ee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [cf231ef0] [c00038b4] do_one_initcall+0x54/0x210 [cf231f20] [c0058ba4] sys_init_module+0x120/0x240 [cf231f40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace 4b412bd05f6f6d8d ]--- # rmmod e300page rmmod: e300page: Device or resource busy 2. Without Ben's patch, there is also oops observed: # insmod ./e300page.ko Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- Segmentation fault Checking dmesg(where you can see the printk msg from the module): Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce172000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- # lsmod Module Size Used by Tainted: G e300page 1549 1 # rmmod e300page rmmod: e300page: Device or resource busy Module source is below: #include <linux/module.h> #include <linux/slab.h> #include <linux/init.h> static int __init e300page_init (void) { static char *kpage; char ch; if (!(kpage = (char *)__get_free_pages (GFP_KERNEL, 0))) { printk (KERN_ERR " __get_free_pages failed\n"); return 0; } printk(KERN_INFO "Read from allocated page\n"); ch = kpage[0]; free_pages ((unsigned long)kpage, 0); printk(KERN_INFO "Write to freed page\n"); kpage[0]='a'; return 0; } static void __exit e300page_exit (void) { printk (KERN_INFO "e300page exiting\n"); } module_init (e300page_init); module_exit (e300page_exit); MODULE_AUTHOR ("Xianghua Xiao"); MODULE_DESCRIPTION ("Test PageAlloc on e300"); MODULE_LICENSE ("GPL v2"); [-- Attachment #2: Type: text/html, Size: 8676 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-05-03 14:19 ` Xianghua Xiao @ 2010-05-04 5:13 ` Benjamin Herrenschmidt 2010-05-06 8:23 ` Maindoor 1 sibling, 0 replies; 9+ messages in thread From: Benjamin Herrenschmidt @ 2010-05-04 5:13 UTC (permalink / raw) To: Xianghua Xiao; +Cc: Maindoor, linuxppc-dev On Mon, 2010-05-03 at 09:19 -0500, Xianghua Xiao wrote: > Ok here is the test result I did this morning, in short with/without > Ben's patch it will oops if you write to a freed page. Probably lucky enough that the free_pages() is pushing the stuff out of the TLB. At least my patch prevents writing to a non-existing hash table though, thus avoiding memory corruption. Cheers, Ben. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-05-03 14:19 ` Xianghua Xiao 2010-05-04 5:13 ` Benjamin Herrenschmidt @ 2010-05-06 8:23 ` Maindoor 2010-05-06 13:04 ` Maindoor 1 sibling, 1 reply; 9+ messages in thread From: Maindoor @ 2010-05-06 8:23 UTC (permalink / raw) To: Xianghua Xiao; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 7772 bytes --] I'm not sure how good of a test this is. I tried the same thing and it seems to workimmediately ie. it gives an oops as soon as "I change the attribute and write to thepage". But when I try to write to it at a later stage as part of an ioctl or after about5 mins, this feature does not seem to work. What if the page is brought in again due to a fault, does the attribute remain the same ? How can I verify this ? RegardsMaindoor. --- On Mon, 5/3/10, Xianghua Xiao <xiaoxianghua@gmail.com> wrote: From: Xianghua Xiao <xiaoxianghua@gmail.com> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Maindoor" <sanjeevfiles@yahoo.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Monday, May 3, 2010, 7:49 PM On Sun, May 2, 2010 at 5:27 AM, Maindoor <sanjeevfiles@yahoo.com> wrote: Any updates on this ? I need something similar. Thanks, Maindoor. --- On Thu, 4/29/10, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" <xiaoxianghua@gmail.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Thursday, April 29, 2010, 3:59 AM On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that is to - get_free_pages a page - read from it - free it - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Ok here is the test result I did this morning, in short with/without Ben's patch it will oops if you write to a freed page. 1. With DEBUG_PAGEALLOC on, after applied Ben's patch and wrote to a freed page, it will oops: -------------------------------------- Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce33c000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: cf231e30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 24000422 XER: 20000000 DAR: ce33c000, DSISR: 22000000 TASK = ce312e10[1395] 'insmod' THREAD: cf230000 GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bfd2ff80 c043d388 00000000 d004d000 c0480000 cf230000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [cf231ee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [cf231ef0] [c00038b4] do_one_initcall+0x54/0x210 [cf231f20] [c0058ba4] sys_init_module+0x120/0x240 [cf231f40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace 4b412bd05f6f6d8d ]--- # rmmod e300page rmmod: e300page: Device or resource busy 2. Without Ben's patch, there is also oops observed: # insmod ./e300page.ko Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- Segmentation fault Checking dmesg(where you can see the printk msg from the module): Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce172000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- # lsmod Module Size Used by Tainted: G e300page 1549 1 # rmmod e300page rmmod: e300page: Device or resource busy Module source is below: #include <linux/module.h> #include <linux/slab.h> #include <linux/init.h> static int __init e300page_init (void) { static char *kpage; char ch; if (!(kpage = (char *)__get_free_pages (GFP_KERNEL, 0))) { printk (KERN_ERR " __get_free_pages failed\n"); return 0; } printk(KERN_INFO "Read from allocated page\n"); ch = kpage[0]; free_pages ((unsigned long)kpage, 0); printk(KERN_INFO "Write to freed page\n"); kpage[0]='a'; return 0; } static void __exit e300page_exit (void) { printk (KERN_INFO "e300page exiting\n"); } module_init (e300page_init); module_exit (e300page_exit); MODULE_AUTHOR ("Xianghua Xiao"); MODULE_DESCRIPTION ("Test PageAlloc on e300"); MODULE_LICENSE ("GPL v2"); -----Inline Attachment Follows----- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev [-- Attachment #2: Type: text/html, Size: 11243 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 2010-05-06 8:23 ` Maindoor @ 2010-05-06 13:04 ` Maindoor 0 siblings, 0 replies; 9+ messages in thread From: Maindoor @ 2010-05-06 13:04 UTC (permalink / raw) To: Xianghua Xiao; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 8436 bytes --] Kind of working, I'll confirm this tomorrow.Was discussed earlier on ppcdev. Had to make somechange in fault handler, for this to work. Regards,Maindoor. --- On Thu, 5/6/10, Maindoor <sanjeevfiles@yahoo.com> wrote: From: Maindoor <sanjeevfiles@yahoo.com> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" <xiaoxianghua@gmail.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Thursday, May 6, 2010, 1:53 PM I'm not sure how good of a test this is. I tried the same thing and it seems to workimmediately ie. it gives an oops as soon as "I change the attribute and write to thepage". But when I try to write to it at a later stage as part of an ioctl or after about5 mins, this feature does not seem to work. What if the page is brought in again due to a fault, does the attribute remain the same ? How can I verify this ? RegardsMaindoor. --- On Mon, 5/3/10, Xianghua Xiao <xiaoxianghua@gmail.com> wrote: From: Xianghua Xiao <xiaoxianghua@gmail.com> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Maindoor" <sanjeevfiles@yahoo.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Monday, May 3, 2010, 7:49 PM On Sun, May 2, 2010 at 5:27 AM, Maindoor <sanjeevfiles@yahoo.com> wrote: Any updates on this ? I need something similar. Thanks, Maindoor. --- On Thu, 4/29/10, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" <xiaoxianghua@gmail.com> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org> Date: Thursday, April 29, 2010, 3:59 AM On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that is to - get_free_pages a page - read from it - free it - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Ok here is the test result I did this morning, in short with/without Ben's patch it will oops if you write to a freed page. 1. With DEBUG_PAGEALLOC on, after applied Ben's patch and wrote to a freed page, it will oops: -------------------------------------- Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce33c000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: cf231e30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 24000422 XER: 20000000 DAR: ce33c000, DSISR: 22000000 TASK = ce312e10[1395] 'insmod' THREAD: cf230000 GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bfd2ff80 c043d388 00000000 d004d000 c0480000 cf230000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [cf231ee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [cf231ef0] [c00038b4] do_one_initcall+0x54/0x210 [cf231f20] [c0058ba4] sys_init_module+0x120/0x240 [cf231f40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace 4b412bd05f6f6d8d ]--- # rmmod e300page rmmod: e300page: Device or resource busy 2. Without Ben's patch, there is also oops observed: # insmod ./e300page.ko Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- Segmentation fault Checking dmesg(where you can see the printk msg from the module): Read from allocated page Write to freed page Unable to handle kernel paging request for data at address 0xce172000 Faulting instruction address: 0xd004d07c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17) MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK = ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] Call Trace: [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable) [ce30bef0] [c00038b4] do_one_initcall+0x54/0x210 [ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 LR = 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 ---[ end trace a05c5135ddb62734 ]--- # lsmod Module Size Used by Tainted: G e300page 1549 1 # rmmod e300page rmmod: e300page: Device or resource busy Module source is below: #include <linux/module.h> #include <linux/slab.h> #include <linux/init.h> static int __init e300page_init (void) { static char *kpage; char ch; if (!(kpage = (char *)__get_free_pages (GFP_KERNEL, 0))) { printk (KERN_ERR " __get_free_pages failed\n"); return 0; } printk(KERN_INFO "Read from allocated page\n"); ch = kpage[0]; free_pages ((unsigned long)kpage, 0); printk(KERN_INFO "Write to freed page\n"); kpage[0]='a'; return 0; } static void __exit e300page_exit (void) { printk (KERN_INFO "e300page exiting\n"); } module_init (e300page_init); module_exit (e300page_exit); MODULE_AUTHOR ("Xianghua Xiao"); MODULE_DESCRIPTION ("Test PageAlloc on e300"); MODULE_LICENSE ("GPL v2"); -----Inline Attachment Follows----- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -----Inline Attachment Follows----- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev [-- Attachment #2: Type: text/html, Size: 11919 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-05-06 13:04 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-28 7:22 [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 Benjamin Herrenschmidt 2010-04-28 19:15 ` Xianghua Xiao 2010-04-28 19:46 ` Kim Phillips 2010-04-28 22:29 ` Benjamin Herrenschmidt 2010-05-02 10:27 ` Maindoor 2010-05-03 14:19 ` Xianghua Xiao 2010-05-04 5:13 ` Benjamin Herrenschmidt 2010-05-06 8:23 ` Maindoor 2010-05-06 13:04 ` Maindoor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).