[PATCH] Fix DEBUG_PAGEALLOC on 603/e300

Maindoor sanjeevfiles at yahoo.com
Thu May 6 23:04:42 EST 2010 

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 at yahoo.com> wrote:

From: Maindoor <sanjeevfiles at yahoo.com>
Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300
To: "Xianghua Xiao" <xiaoxianghua at gmail.com>
Cc: "linuxppc-dev" <linuxppc-dev at 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 at gmail.com> wrote:

From: Xianghua Xiao <xiaoxianghua at gmail.com>
Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on
 603/e300
To: "Maindoor" <sanjeevfiles at yahoo.com>
Cc: "linuxppc-dev" <linuxppc-dev at lists.ozlabs.org>
Date: Monday, May 3, 2010, 7:49 PM

On Sun, May 2, 2010 at 5:27 AM, Maindoor <sanjeevfiles at yahoo.com> wrote:


Any updates on this ? I need something similar.

Thanks,
Maindoor.

--- On Thu, 4/29/10, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:


From: Benjamin Herrenschmidt <benh at kernel.crashing.org>

Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300
To: "Xianghua Xiao" <xiaoxianghua at gmail.com>
Cc: "linuxppc-dev" <linuxppc-dev at 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 at 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 at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


      
-----Inline Attachment Follows-----

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20100506/4a87335a/attachment-0001.htm>

More information about the Linuxppc-dev mailing list