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 patch
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
Scott Wood 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 do_page_fault()
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
Scott Wood 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 the missi
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 ever
Benjamin Herrenschmidt 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 was to long
time ago
Joakim Tjernlund wrote:
Benjamin Herrenschmidt 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 was
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 oop
Rex Feany 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 need th
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);
> > c000e11
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
Rex Feany 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 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 fault.
> > >
Benjamin Herrenschmidt 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 fault.
> > >
\
> 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
Rex Feany 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 r
Benjamin Herrenschmidt 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
> > --- a/arch/powerpc/mm/fault.c
> > 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 a/a
>
>
> > > 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, se
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 reg
Benjamin Herrenschmidt wrote on 06/10/2009 13:06:26:
> From:
>
> Benjamin Herrenschmidt
>
> To:
>
> Joakim Tjernlund
>
> Cc:
>
> "linuxppc-...@ozlabs.org" , Rex Feany
> , Scott Wood
>
> Date:
>
> 06/10/2009 13:06
>
> Subject:
&
Benjamin Herrenschmidt 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, you can probably
25 matches
Mail list logo
