Rex Feany rfe...@mrv.com wrote on 06/10/2009 00:42:18:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
I got this oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc000e110
Oops: Kernel access of bad area,
I assumed it was NIP because ... I'm not sure why. TRAP() above
dereferences regs, and that didn't fail, but I didn't see that until
now.
Yes, it is a bit strange though that the kernel isn't allowed to read from
NULL. Is that expected?
Yes, that's absolutely expected :-) You really
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 03:52:15:
\
So how does this look? Does it change anything?
It should as the previous way was way off :(
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index c33c6de..08a392f 100644
---
No, use get_user() not __get_user() or if you use the later, also use
access_ok(), and test the result in case it errors (if it does, you
probably want to just goto bad access and SEGV).
OK, lets see what this gives us:
Hrm... did you change anything ? :-)
Ben.
diff --git
No, use get_user() not __get_user() or if you use the later, also use
access_ok(), and test the result in case it errors (if it does, you
probably want to just goto bad access and SEGV).
OK, lets see what this gives us:
Hrm... did you change anything ? :-)
Yes, see below
Ben.
On Tue, 2009-10-06 at 12:58 +0200, Joakim Tjernlund wrote:
Here I don't care if err. insn will be 0 if it fails and the following
if will be false
I'd rather you use get_user() so it does access_ok().
Else, you can probably manufacture some code that will make the kernel
access some MMIO
...@freescale.com
Date:
06/10/2009 13:06
Subject:
Re: [PATCH 0/6] PowerPc 8xx TLB/MMU fixes
On Tue, 2009-10-06 at 12:58 +0200, Joakim Tjernlund wrote:
Here I don't care if err. insn will be 0 if it fails and the following
if will be false
I'd rather you use get_user() so it does
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 13:06:26:
On Tue, 2009-10-06 at 12:58 +0200, Joakim Tjernlund wrote:
Here I don't care if err. insn will be 0 if it fails and the following
if will be false
I'd rather you use get_user() so it does access_ok().
Else,
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to do_page_fault() is
purely a debug check and will be removed/disabled when
this series appear stable.
Scott and Rex, please disregard other
On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to do_page_fault() is
purely a debug check and will be removed/disabled when
Scott Wood scottw...@freescale.com wrote on 05/10/2009 20:12:34:
On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to
On Mon, Oct 05, 2009 at 08:27:39PM +0200, Joakim Tjernlund wrote:
After resolving the conflict, without adding tlbil_va in do_page_fault(), I
get the same stuck behavior as before.
Expected, I havn't not tried to fix the missing tlbil_va(). That is
different problem that you and Ben needs
Scott Wood scottw...@freescale.com wrote on 05/10/2009 22:09:41:
On Mon, Oct 05, 2009 at 08:27:39PM +0200, Joakim Tjernlund wrote:
After resolving the conflict, without adding tlbil_va in do_page_fault(),
I
get the same stuck behavior as before.
Expected, I havn't not tried to fix
Joakim Tjernlund wrote:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Maybe you see some version of the dcbX bug, but my fault.c should
fix them up. My bet would be the 32 byte cache line, it will miss
out every second line and so the results are unreliable.
I found the 32-byte
On Mon, 2009-10-05 at 23:04 +0200, Joakim Tjernlund wrote:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
Maybe you see some version of the dcbX bug, but my fault.c should
fix them up. My bet would be the 32 byte cache line, it will miss
out every
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 23:31:39:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
hmm, maybe not. Can't remember now. But perhaps LAZY relocs still
need dcbX? Easiest is to check in uClibc. I impl. it, but
Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 23:31:39:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
hmm, maybe not. Can't remember now. But perhaps LAZY relocs still
need dcbX? Easiest is to check in
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Scott and Rex, please disregard other patches from me and
try these out instead.
I have results similar to Scott's. I tried both with and without patch
5 6, and I also need the tlbia_va in ptep_set_access_flags().
I got this oops:
Rex Feany rfe...@mrv.com wrote on 06/10/2009 00:04:20:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Scott and Rex, please disregard other patches from me and
try these out instead.
I have results similar to Scott's. I tried both with and without patch
5 6, and I also
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page fault.
insn = *((unsigned long *)regs-nip);
c000e110: 80
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
I got this oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc000e110
Oops: Kernel access of bad area, sig: 11 [#1]
MRV NM2
NIP: c000e110 LR: c000d520 CTR: 1006bf40
Rex Feany rfe...@mrv.com wrote on 06/10/2009 00:42:18:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
I got this oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc000e110
Oops: Kernel access of bad area,
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 00:37:28:
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 00:37:28:
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page
\
So how does this look? Does it change anything?
It should as the previous way was way off :(
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index c33c6de..08a392f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -153,7 +153,7 @@ int __kprobes
25 matches
Mail list logo
