[RFC -mm][PATCH 5/6] prepare kprobes code for x86 unification

[Jim Keniston]

On Tue, 2007-12-11 at 11:40 -0500, Masami Hiramatsu wrote:
> Hi Arjan,
> 
> Thank you for comment.
> Arjan van de Ven wrote:
> > On Mon, 10 Dec 2007 17:53:22 -0500
> > Masami Hiramatsu <mhiramat@redhat.com> wrote:
> >> +#define stack_addr(regs) ((unsigned long *)&regs->sp)
> > 
> > Hi,
> > 
> > thanks for taking up this work again, however this line has a bug (yes it's a bug in the 32 bit retprobes);
> > the address of the stack is regs->sp not &regs->sp, since &regs->sp is the address of the 
> > memory we store the stackpointer in, not the actual address on the stack...
> 
> As far as I know, it is true on x86-64, but it's not true on x86-32(kernel mode).
> I checked it in __show_registers()@arch/x86/kernel/process_32.c.
> 
> Here is that code:
> >         if (user_mode_vm(regs)) {
> >                 sp = regs->sp;
> >                 ss = regs->ss & 0xffff;
> >                 savesegment(gs, gs);
> >         } else {
> >                 sp = (unsigned long) (&regs->sp);
> >                 savesegment(ss, ss);
> >                 savesegment(gs, gs);
> >         }
> 
> So, in kernel mode, &regs->sp is the address of the top of stack.
> 
> Best Regards,
> 
> > 
> > Greetings,
> >   Arjan van de Ven

Masami is correct.  x86_32 CPUs don't save the ss and esp registers if
the CPU is already in kernel mode when it traps.  So in this case,
regs->esp and regs->xss are not the [nonexistent] saved stack pointer
and ss register, but rather the last 8 bytes of the pre-int3 stack.  So
&regs->esp happens to point to the top of the pre-int3 stack.

Jim