On Thu, 14 Jul 2011 08:27:44 -0500 Kumar Gala <ga...@kernel.crashing.org> wrote:
> > On Jul 11, 2011, at 6:31 AM, Tiejun Chen wrote: > > > When kprobe these operations such as store-and-update-word for SP(r1), > > > > stwu r1, -A(r1) > > > > The program exception is triggered, and PPC always allocate an exception > > frame > > as shown as the follows: > > > > old r1 ---------- > > ... > > nip > > gpr[2] ~ gpr[31] > > gpr[1] <--------- old r1 is stored. > > gpr[0] > > -------- <--------- pr_regs @offset 16 bytes > > padding > > STACK_FRAME_REGS_MARKER > > LR > > back chain > > new r1 ---------- > > Then emulate_step() will emulate this instruction, 'stwu'. Actually its > > equivalent to: > > 1> Update pr_regs->gpr[1] = mem[old r1 + (-A)] > > 2> stw [old r1], mem[old r1 + (-A)] > > > > Please notice the stack based on new r1 may be covered with mem[old r1 > > +(-A)] when addr[old r1 + (-A)] < addr[old r1 + sizeof(an exception frame0]. > > So the above 2# operation will overwirte something to break this exception > > frame then unexpected kernel problem will be issued. > > > > So looks we have to implement independed interrupt stack for PPC program > > exception when CONFIG_BOOKE is enabled. Here we can use > > EXC_LEVEL_EXCEPTION_PROLOG to replace original NORMAL_EXCEPTION_PROLOG > > for program exception if CONFIG_BOOKE. Then its always safe for kprobe > > with independed exc stack from one pre-allocated and dedicated thread_info. > > Actually this is just waht we did for critical/machine check exceptions > > on PPC. > > > > Signed-off-by: Tiejun Chen <tiejun.c...@windriver.com> > > --- > > I'm still very confused why we need a unique stack frame for kprobe/program > exceptions on book-e devices. I don't know why it's booke-specific (or why they're emulating rather than using single-step), but the problem is trying to emulate an instruction that's expanding the non-exception stack into the area that the exception handler is sitting on, and writing to that new stack area. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
