Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Aug 23, 2011 at 02:01:46AM +0100, Al Viro wrote:

> now, what is going to happen to %ebp if we go through IRET path, for any
> reason?  From my reading it appears that right after that IRET we'll have
> ebp containing arg6.  I.e. what we'd pushed on stack.  Now, popl %ebp
> will bring the same value back.  Not a problem.  But what about
> movl %ebp, %ecx?  Again, I'm talking about the case when we have no
> restart at all - just an strace(1) tracing a process.
> 
> AFAICS, in that case we ought to have %ecx == %ebp after return from
> __kernel_vsyscall().  Which would blow the things up _very_ fast.
> 
> So what the hell am I missing here?

*UGH*.  OK,
	1) I'm an idiot; int_ret_from_sys_call does *not* usually step on
rbp (it's callee-saved).  So normally ebp is left as is on the way out,
which is why we don't see stuff getting buggered left, right and center.
	2) Sometimes it apparently does somehow happen.  I don't see where
it happens yet, but uml breakage that started all of that looks *exactly*
like that.  %ebp getting arg6 in it when we return into __kernel_vsyscall()
from the kernel fits the observed pattern precisely.
	3) modulo that the situation is nowhere near as bad as I thought.
Brown paperbag time for me - for missing that if my analysis had been correct
we'd've seen breakage _much_ earlier.  Mea culpa.
	4) we still have a problem, apparently, but it's more narrow now -
the question is when would %rbp be shat into?

Al, off to apply a serious self-LART...