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. Can you explain this further. - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
