From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from web63004.mail.re1.yahoo.com (web63004.mail.re1.yahoo.com [69.147.96.215]) by ozlabs.org (Postfix) with SMTP id 5C2CAB6EFF for ; Thu, 6 May 2010 23:04:45 +1000 (EST) Message-ID: <259490.45078.qm@web63004.mail.re1.yahoo.com> Date: Thu, 6 May 2010 06:04:42 -0700 (PDT) From: Maindoor Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: Xianghua Xiao In-Reply-To: <250576.54231.qm@web63002.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-973823396-1273151082=:45078" Cc: linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --0-973823396-1273151082=:45078 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Kind of working, I'll confirm this tomorrow.Was discussed earlier on ppcdev= . Had to make somechange in fault handler, for this to work.=A0 Regards,Maindoor. --- On Thu, 5/6/10, Maindoor wrote: From: Maindoor Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" Cc: "linuxppc-dev" 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 seem= s to workimmediately ie. it gives an oops as soon as "I change the attribut= e 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.= =A0What if the page is brought in again due to a fault, does the attribute = remain=A0the =A0same ? How can I verify this ?=A0 RegardsMaindoor. --- On Mon, 5/3/10, Xianghua Xiao wrote: From: Xianghua Xiao Subject: Re: [PATCH] Fix DEBUG_PAGEALLOC on=0A 603/e300 To: "Maindoor" Cc: "linuxppc-dev" Date: Monday, May 3, 2010, 7:49 PM On Sun, May 2, 2010 at 5:27 AM, Maindoor wrote: =0A=0AAny updates on this ? I need something similar. Thanks, Maindoor. --- On Thu, 4/29/10, Benjamin Herrenschmidt wrot= e: =0A From: Benjamin Herrenschmidt =0ASubject: Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300 To: "Xianghua Xiao" Cc: "linuxppc-dev" =0ADate: 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. =0A But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that=0A is to =A0=A0=A0 - get_free_pages a page =A0=A0=A0 - read from it =A0=A0=A0 - free it =A0=A0=A0 - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. =0A _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev =0A 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: =0A-------------------------------------- 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] =0APREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: cf231e30 TRAP: 0300=A0=A0 Not tainted=A0 (2.6.33.3-rt17) MSR: 00009032 =A0 CR: 24000422=A0 XER: 20000000 =0ADAR: ce33c000, DSISR: 22000000 TASK =3D ce312e10[1395] 'insmod' THREAD: cf230000 GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d ffffffff c047c4d6 00004= 000=20 GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422 100bbc1c 0fffd000 fffff= fff=20 =0AGPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 10= 0b90a0=20 GPR24: 4800e4ac bfd2ff80 c043d388 00000000 d004d000 c0480000 cf230000 d0050= 000=20 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] =0ACall 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 =0A--- Exception: c01 at 0xfe5baa0 =A0=A0=A0 LR =3D 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005=20 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035= =20 =0A---[ end trace 4b412bd05f6f6d8d ]--- # rmmod e300page rmmod: e300page: Device or resource busy 2. Without Ben's patch, there is also oops observed: # insmod ./e300page.ko=20 Oops: Kernel access of bad area, sig: 11 [#1] =0APREEMPT DEBUG_PAGEALLOC 834x SYS Modules linked in: e300page(+) NIP: d004d07c LR: d004d074 CTR: 00000001 REGS: ce30be30 TRAP: 0300=A0=A0 Not tainted=A0 (2.6.33.3-rt17) MSR: 00009032 =A0 CR: 22000422=A0 XER: 20000000 =0ADAR: ce172000, DSISR: 22000000 TASK =3D ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004= 000=20 GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 fffff= fff=20 =0AGPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 10= 0b90a0=20 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050= 000=20 NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page] LR [d004d074] e300page_init+0x74/0xb8 [e300page] =0ACall 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 =0A--- Exception: c01 at 0xfe5baa0 =A0=A0=A0 LR =3D 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005=20 3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c035= =20 =0A---[ 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 =0AFaulting 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=A0=A0 Not tainted=A0 (2.6.33.3-rt17) =0AMSR: 00009032 =A0 CR: 22000422=A0 XER: 20000000 DAR: ce172000, DSISR: 22000000 TASK =3D ce306120[1392] 'insmod' THREAD: ce30a000 GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004= 000=20 =0AGPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 ff= ffffff=20 GPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 00000000 100b9= 0a0=20 GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c0480000 ce30a000 d0050= 000=20 =0ANIP [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 =0A[ce30bf20] [c0058bb0] sys_init_module+0x120/0x240 [ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe5baa0 =A0=A0=A0 LR =3D 0x10027de0 Instruction dump: 4e800020 3c60d005 3863a094 48000031 807fa214 38800000 48000045 3c60d005=20 =0A3863a0b4 48000019 813fa214 38000061 <98090000> 4bffffb8 00000000 3d60c03= 5=20 ---[ end trace a05c5135ddb62734 ]--- # lsmod Module=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 Used by= =A0=A0=A0 Tainted: G=A0=20 e300page=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1549=A0 1=20 =0A# rmmod e300page rmmod: e300page: Device or resource busy Module source is below: #include #include #include static int __init e300page_init (void) =0A{ =A0=A0=A0=A0=A0=A0=A0 static char *kpage; =A0=A0=A0=A0=A0=A0=A0 char ch; =A0=A0=A0=A0=A0=A0=A0 if (!(kpage =3D (char *)__get_free_pages (GFP_KERNEL,= 0))) { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printk (KERN_ERR " __get_free= _pages failed\n"); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0; =0A=A0=A0=A0=A0=A0=A0=A0 } =A0=A0=A0=A0=A0=A0=A0 printk(KERN_INFO "Read from allocated page\n"); =A0=A0=A0=A0=A0=A0=A0 ch =3D kpage[0]; =A0=A0=A0=A0=A0=A0=A0 free_pages ((unsigned long)kpage, 0); =A0=A0=A0=A0=A0=A0=A0 printk(KERN_INFO "Write to freed page\n"); =0A=A0=A0=A0=A0=A0=A0=A0 kpage[0]=3D'a'; =A0=A0=A0=A0=A0=A0=A0 return 0; } static void __exit e300page_exit (void) { =A0=A0=A0=A0=A0=A0=A0 printk (KERN_INFO "e300page exiting\n"); } module_init (e300page_init); module_exit (e300page_exit); =0A MODULE_AUTHOR ("Xianghua Xiao"); MODULE_DESCRIPTION ("Test PageAlloc on e300"); MODULE_LICENSE ("GPL v2"); =0A -----Inline Attachment Follows----- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev =0A=0A =20 -----Inline Attachment Follows----- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev=0A=0A=0A --0-973823396-1273151082=:45078 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Kind of working, I'll confirm this tomorr= ow.
Was discussed earlier on ppcdev. Had to make some
change = in fault handler, for this to work. 

Regards,=
Maindoor.
--- On Thu, 5/6/10, Maindoor <sanjeevfiles= @yahoo.com> wrote:

From: Maindoo= r <sanjeevfiles@yahoo.com>
Subject: Re: [PATCH] Fix DEBUG_PAGEALLO= C 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


=0A=0A
-----Inline Attachment Follows-----

=
_______________________________________________Linuxppc-dev mailing list
Linuxppc-dev= @lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
I'm not sure how good of a test this is. I tried the same thing = and it seems to work
immediately ie. it gives an oops as soon as "I change the attribu= te and write to the
page". But when I try to write to it at a lat= er stage as part of an ioctl or after about
5 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 ? 

Regards
M= aindoor.




--- On Mon, 5/3/10, X= ianghua Xiao <xiaoxianghua@gmail.com> wrote:

From: Xianghua Xiao <xiaoxianghua@gmail.com>
Subject= : Re: [PATCH] Fix DEBUG_PAGEALLOC on=0A 603/e300
To: "Maindoor" <sanj= eevfiles@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:
=0A
=0AAny updates on this ? I need something simi= lar.

Thanks,
Maindoor.

--- On Thu, 4/29/10, Benjamin He= rrenschmidt <benh@kernel.crashing.org>= wrote:
=0A

From: Benjamin Herrenschmidt <= benh@kernel.crashing.org>
=0ASubject: Re: [PA= TCH] Fix DEBUG_PAGEALLOC on 603/e300
To: "Xianghua Xiao" <xiaoxianghua@gmail.com>
Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
=0ADate: Thursday, Apri= l 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.
= =0A
But have you tested that DEBUG_PAGEALLOC actually works ? :-)
A way to do that=0A is to

    - get_free_pages a pag= e
    - read from it
    - free it
&= nbsp;   - write to it

It should oops on the write, and I s= uspect that without my patch it
doesn't.

Cheers,
Ben.

= =0A
_______________________________________________
Linuxppc-dev mail= ing list
Linuxppc-dev@lists.ozlabs.org
<= a rel=3D"nofollow" target=3D"_blank" href=3D"https://lists.ozlabs.org/listi= nfo/linuxppc-dev">https://lists.ozlabs.org/listinfo/linuxppc-dev
=0A=

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:
=0A-= -------------------------------------
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 acc= ess of bad area, sig: 11 [#1]
=0APREEMPT DEBUG_PAGEALLOC 834x SYS
Mod= ules 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=0ADAR: ce33c000, DSISR: 22000000
TASK =3D ce312e10[1395] 'insmod' THRE= AD: cf230000
GPR00: 00000061 cf231ee0 ce312e10 0000001a 00003b0d fffffff= f c047c4d6 00004000
GPR08: c047c8c4 ce33c000 00003fff ce312e10 24000422= 100bbc1c 0fffd000 ffffffff
=0AGPR16: 00000001 00000000 007fff00 000000= 00 00000000 0fffa1a0 00000000 100b90a0
GPR24: 4800e4ac bfd2ff80 c043d38= 8 00000000 d004d000 c0480000 cf230000 d0050000
NIP [d004d07c] e300page_= init+0x7c/0xb8 [e300page]
LR [d004d074] e300page_init+0x74/0xb8 [e300pag= e]
=0ACall Trace:
[cf231ee0] [d004d074] e300page_init+0x74/0xb8 [e300= page] (unreliable)
[cf231ef0] [c00038b4] do_one_initcall+0x54/0x210
[= cf231f20] [c0058ba4] sys_init_module+0x120/0x240
[cf231f40] [c0012afc] r= et_from_syscall+0x0/0x38
=0A--- Exception: c01 at 0xfe5baa0
 &nb= sp;  LR =3D 0x10027de0
Instruction dump:
4e800020 3c60d005 3863a= 094 48000031 807fa214 38800000 48000045 3c60d005
3863a0b4 48000019 813f= a214 38000061 <98090000> 4bffffb8 00000000 3d60c035
=0A---[ end t= race 4b412bd05f6f6d8d ]---

# rmmod e300page
rmmod: e300page: Devi= ce or resource busy

2. Without Ben's patch, there is also oops obser= ved:
# insmod ./e300page.ko
Oops: Kernel access of bad area, sig: 11= [#1]
=0APREEMPT DEBUG_PAGEALLOC 834x SYS
Modules linked in: e300page= (+)
NIP: d004d07c LR: d004d074 CTR: 00000001
REGS: ce30be30 TRAP: 030= 0   Not tainted  (2.6.33.3-rt17)
MSR: 00009032 <EE,ME,= IR,DR>  CR: 22000422  XER: 20000000
=0ADAR: ce172000, DSISR= : 22000000
TASK =3D ce306120[1392] 'insmod' THREAD: ce30a000
GPR00: 0= 0000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 00004000
= GPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0fffd000 fffff= fff
=0AGPR16: 00000001 00000000 007fff00 00000000 00000000 0fffa1a0 000= 00000 100b90a0
GPR24: 4800e4ac bf876f10 c043d388 00000000 d004d000 c048= 0000 ce30a000 d0050000
NIP [d004d07c] e300page_init+0x7c/0xb8 [e300page= ]
LR [d004d074] e300page_init+0x74/0xb8 [e300page]
=0ACall Trace:
= [ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliable)
[c= e30bef0] [c00038b4] do_one_initcall+0x54/0x210
[ce30bf20] [c0058bb0] sys= _init_module+0x120/0x240
[ce30bf40] [c0012afc] ret_from_syscall+0x0/0x38=
=0A--- Exception: c01 at 0xfe5baa0
    LR =3D 0x10027= de0
Instruction dump:
4e800020 3c60d005 3863a094 48000031 807fa214 38= 800000 48000045 3c60d005
3863a0b4 48000019 813fa214 38000061 <980900= 00> 4bffffb8 00000000 3d60c035
=0A---[ end trace a05c5135ddb62734 ]-= --
Segmentation fault

Checking dmesg(where you can see the printk= msg from the module):
Read from allocated page
Write to freed pageUnable to handle kernel paging request for data at address 0xce172000
= =0AFaulting instruction address: 0xd004d07c
Oops: Kernel access of bad a= rea, 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)
=0AMSR: 0000903= 2 <EE,ME,IR,DR>  CR: 22000422  XER: 20000000
DAR: ce1720= 00, DSISR: 22000000
TASK =3D ce306120[1392] 'insmod' THREAD: ce30a000GPR00: 00000061 ce30bee0 ce306120 0000001a 00003b0d ffffffff c047c4d6 0000= 4000
=0AGPR08: c047c8c4 ce172000 00003fff ce306120 22000422 100bbc1c 0f= ffd000 ffffffff
GPR16: 00000001 00000000 007fff00 00000000 00000000 0ff= fa1a0 00000000 100b90a0
GPR24: 4800e4ac bf876f10 c043d388 00000000 d004= d000 c0480000 ce30a000 d0050000
=0ANIP [d004d07c] e300page_init+0x7c/0x= b8 [e300page]
LR [d004d074] e300page_init+0x74/0xb8 [e300page]
Call T= race:
[ce30bee0] [d004d074] e300page_init+0x74/0xb8 [e300page] (unreliab= le)
[ce30bef0] [c00038b4] do_one_initcall+0x54/0x210
=0A[ce30bf20] [c= 0058bb0] sys_init_module+0x120/0x240
[ce30bf40] [c0012afc] ret_from_sysc= all+0x0/0x38
--- Exception: c01 at 0xfe5baa0
    LR = =3D 0x10027de0
Instruction dump:
4e800020 3c60d005 3863a094 48000031 = 807fa214 38800000 48000045 3c60d005
=0A3863a0b4 48000019 813fa214 38000= 061 <98090000> 4bffffb8 00000000 3d60c035
---[ end trace a05c5135= ddb62734 ]---

# lsmod
Module      &= nbsp;           Size = ; Used by    Tainted: G 
e300page   =              15= 49  1
=0A# rmmod e300page
rmmod: e300page: Device or resource b= usy

Module source is below:
#include <linux/module.h>
#i= nclude <linux/slab.h>
#include <linux/init.h>

static = int __init e300page_init (void)
=0A{
     &n= bsp;  static char *kpage;
       = ; char ch;

        if (!(kpage = =3D (char *)__get_free_pages (GFP_KERNEL, 0))) {
    = ;            printk = (KERN_ERR " __get_free_pages failed\n");
     &= nbsp;          return 0;
= =0A        }

   &n= bsp;    printk(KERN_INFO "Read from allocated page\n");
&= nbsp;       ch =3D kpage[0];
  &= nbsp;     free_pages ((unsigned long)kpage, 0);
&nbs= p;       printk(KERN_INFO "Write to freed pag= e\n");
=0A        kpage[0]=3D'a';
=
        return 0;
}
static voi= d __exit e300page_exit (void)
{
      &= nbsp; printk (KERN_INFO "e300page exiting\n");
}

module_init (e30= 0page_init);
module_exit (e300page_exit);
=0A
MODULE_AUTHOR ("Xian= ghua Xiao");
MODULE_DESCRIPTION ("Test PageAlloc on e300");
MODULE_LI= CENSE ("GPL v2");

=0A

-----Inline Attachment Fo= llows-----

________________________________= _______________
Linuxppc-dev mailing list
Linuxpp= c-dev@lists.ozlabs.org
https://lists.ozlabs.org/l= istinfo/linuxppc-dev

=0A=0A --0-973823396-1273151082=:45078--