<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">I'm not sure how good of a test this is. I tried the same thing and it seems to work<div>immediately ie. it gives an oops as soon as "I change the attribute and write to the</div><div>page". But when I try to write to it at a later stage as part of an ioctl or after about</div><div>5 mins, this feature does not seem to work. </div><div>What if the page is brought in again due to a fault, does the attribute remain </div><div>the same ? How can I verify this ? </div><div><br></div><div>Regards</div><div>Maindoor.</div><div><br></div><div><br><br><div><br>--- On <b>Mon, 5/3/10, Xianghua Xiao <i><xiaoxianghua@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Xianghua Xiao <xiaoxianghua@gmail.com><br>Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on
603/e300<br>To: "Maindoor" <sanjeevfiles@yahoo.com><br>Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org><br>Date: Monday, May 3, 2010, 7:49 PM<br><br><div id="yiv1471012639"><div class="gmail_quote">On Sun, May 2, 2010 at 5:27 AM, Maindoor <span dir="ltr"><<a rel="nofollow" ymailto="mailto:sanjeevfiles@yahoo.com" target="_blank" href="/mc/compose?to=sanjeevfiles@yahoo.com">sanjeevfiles@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family:inherit;font-style:inherit;font-variant:inherit;font-weight:inherit;font-size:inherit;line-height:inherit;font-size-adjust:inherit;font-stretch:inherit;" valign="top">
Any updates on this ? I need something similar.<br><br>Thanks,<br>Maindoor.<br><br>--- On <b>Thu, 4/29/10, Benjamin Herrenschmidt <i><<a rel="nofollow" ymailto="mailto:benh@kernel.crashing.org" target="_blank" href="/mc/compose?to=benh@kernel.crashing.org">benh@kernel.crashing.org</a>></i></b> wrote:<br>
<blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;"><br>From: Benjamin Herrenschmidt <<a rel="nofollow" ymailto="mailto:benh@kernel.crashing.org" target="_blank" href="/mc/compose?to=benh@kernel.crashing.org">benh@kernel.crashing.org</a>><br>
Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300<br>To: "Xianghua Xiao" <<a rel="nofollow" ymailto="mailto:xiaoxianghua@gmail.com" target="_blank" href="/mc/compose?to=xiaoxianghua@gmail.com">xiaoxianghua@gmail.com</a>><br>Cc: "linuxppc-dev" <<a rel="nofollow" ymailto="mailto:linuxppc-dev@lists.ozlabs.org" target="_blank" href="/mc/compose?to=linuxppc-dev@lists.ozlabs.org">linuxppc-dev@lists.ozlabs.org</a>><br>
Date: Thursday, April 29, 2010, 3:59 AM<br><br><div>On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote:<br>> This change works me on a 834x(e300) platform, tested with lmbench and<br>> a production-ready application with 2.6.33.3.<br>
<br>But have you tested that DEBUG_PAGEALLOC actually works ? :-)<br><br>A way to do that
is to<br><br> - get_free_pages a page<br> - read from it<br> - free it<br> - write to it<br><br>It should oops on the write, and I suspect that without my patch it<br>doesn't.<br><br>Cheers,<br>Ben.<br><br>
<br>_______________________________________________<br>Linuxppc-dev mailing list<br><a rel="nofollow" target="_blank" href="http://mc/compose?to=Linuxppc-dev@lists.ozlabs.org">Linuxppc-dev@lists.ozlabs.org</a><br><a rel="nofollow" target="_blank" href="https://lists.ozlabs.org/listinfo/linuxppc-dev">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br>
</div></blockquote></td></tr></tbody></table><br></blockquote><div>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.<br><br>1. With DEBUG_PAGEALLOC on, after applied Ben's patch and wrote to a freed page, it will oops:<br>
--------------------------------------<br>Read from allocated page<br>Write to freed page<br>Unable to handle kernel paging request for data at address 0xce33c000<br>Faulting instruction address: 0xd004d07c<br>Oops: Kernel access of bad area, sig: 11 [#1]<br>
PREEMPT DEBUG_PAGEALLOC 834x SYS<br>Modules linked in: e300page(+)<br>NIP: d004d07c LR: d004d074 CTR: 00000001<br>REGS: cf231e30 TRAP: 0300 Not tainted (2.6.33.3-rt17)<br>MSR: 00009032 <EE,ME,IR,DR> CR: 24000422 XER: 20000000<br>
DAR: ce33c000, DSISR: 22000000<br>TASK = ce312e10[1395] 'insmod' THREAD: cf230000<br>GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d ffffffff c047c4d6 00004000 <br>GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422 100bbc1c 0fffd000 ffffffff <br>
GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 <br>GPR24: 4800e4ac bfd2ff80 c043d388 00000000 d004d000 c0480000 cf230000 d0050000 <br>NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page]<br>LR [d004d074] e300page_init+0x74/0xb8 [e300page]<br>
Call Trace:<br>[cf231ee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable)<br>[cf231ef0] [c00038b4] do_one_initcall+0x54/0x210<br>[cf231f20] [c0058ba4] sys_init_module+0x120/0x240<br>[cf231f40] [c0012afc] ret_from_syscall+0x0/0x38<br>
--- Exception: c01 at 0xfe5baa0<br> LR = 0x10027de0<br>Instruction dump:<br>4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 <br>3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 <br>
---[ end trace 4b412bd05f6f6d8d ]---<br><br># rmmod e300page<br>rmmod: e300page: Device or resource busy<br><br>2. Without Ben's patch, there is also oops observed:<br># insmod ./e300page.ko <br>Oops: Kernel access of bad area, sig: 11 [#1]<br>
PREEMPT DEBUG_PAGEALLOC 834x SYS<br>Modules linked in: e300page(+)<br>NIP: d004d07c LR: d004d074 CTR: 00000001<br>REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17)<br>MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000<br>
DAR: ce172000, DSISR: 22000000<br>TASK = ce306120[1392] 'insmod' THREAD: ce30a000<br>GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 <br>GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff <br>
GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 <br>GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 <br>NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page]<br>LR [d004d074] e300page_init+0x74/0xb8 [e300page]<br>
Call Trace:<br>[ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable)<br>[ce30bef0] [c00038b4] do_one_initcall+0x54/0x210<br>[ce30bf20] [c0058bb0] sys_init_module+0x120/0x240<br>[ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38<br>
--- Exception: c01 at 0xfe5baa0<br> LR = 0x10027de0<br>Instruction dump:<br>4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 <br>3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 <br>
---[ end trace a05c5135ddb62734 ]---<br>Segmentation fault<br><br>Checking dmesg(where you can see the printk msg from the module):<br>Read from allocated page<br>Write to freed page<br>Unable to handle kernel paging request for data at address 0xce172000<br>
Faulting instruction address: 0xd004d07c<br>Oops: Kernel access of bad area, sig: 11 [#1]<br>PREEMPT DEBUG_PAGEALLOC 834x SYS<br>Modules linked in: e300page(+)<br>NIP: d004d07c LR: d004d074 CTR: 00000001<br>REGS: ce30be30 TRAP: 0300 Not tainted (2.6.33.3-rt17)<br>
MSR: 00009032 <EE,ME,IR,DR> CR: 22000422 XER: 20000000<br>DAR: ce172000, DSISR: 22000000<br>TASK = ce306120[1392] 'insmod' THREAD: ce30a000<br>GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000 <br>
GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ffffffff <br>GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b90a0 <br>GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050000 <br>
NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page]<br>LR [d004d074] e300page_init+0x74/0xb8 [e300page]<br>Call Trace:<br>[ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable)<br>[ce30bef0] [c00038b4] do_one_initcall+0x54/0x210<br>
[ce30bf20] [c0058bb0] sys_init_module+0x120/0x240<br>[ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38<br>--- Exception: c01 at 0xfe5baa0<br> LR = 0x10027de0<br>Instruction dump:<br>4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005 <br>
3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035 <br>---[ end trace a05c5135ddb62734 ]---<br><br># lsmod<br>Module Size Used by Tainted: G <br>e300page 1549 1 <br>
# rmmod e300page<br>rmmod: e300page: Device or resource busy<br><br>Module source is below:<br>#include <linux/module.h><br>#include <linux/slab.h><br>#include <linux/init.h><br><br>static int __init e300page_init (void)<br>
{<br> static char *kpage;<br> char ch;<br><br> if (!(kpage = (char *)__get_free_pages (GFP_KERNEL, 0))) {<br> printk (KERN_ERR " __get_free_pages failed\n");<br> return 0;<br>
}<br><br> printk(KERN_INFO "Read from allocated page\n");<br> ch = kpage[0];<br> free_pages ((unsigned long)kpage, 0);<br> printk(KERN_INFO "Write to freed page\n");<br>
kpage[0]='a';<br><br> return 0;<br>}<br>static void __exit e300page_exit (void)<br>{<br> printk (KERN_INFO "e300page exiting\n");<br>}<br><br>module_init (e300page_init);<br>module_exit (e300page_exit);<br>
<br>MODULE_AUTHOR ("Xianghua Xiao");<br>MODULE_DESCRIPTION ("Test PageAlloc on e300");<br>MODULE_LICENSE ("GPL v2");<br><br></div></div>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>Linuxppc-dev mailing list<br><a ymailto="mailto:Linuxppc-dev@lists.ozlabs.org" href="/mc/compose?to=Linuxppc-dev@lists.ozlabs.org">Linuxppc-dev@lists.ozlabs.org</a><br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_blank">https://lists.ozlabs.org/listinfo/linuxppc-dev</a></div></blockquote></div></div></td></tr></table><br>