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 Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:

> You guys seem to positively _want_ to make this a bigger issue than it
> is. As far as I can tell, nobody has ever even noticed this problem
> before, and we already have a trivial fix ("don't do it then") for the
> case Al actually did notice.

I'm not sure.   What I've noticed was complete weirdness in uml, apparently
dependent on SYSCALL vs. SYSENTER or int 0x80.  With following round of
RTFS and finding what looks like an ugly issue with restarts.

What I don't understand at all is how the hell do we manage to avoid much
more obvious breakage all the time we ptrace a 32bit task.  Look:
__kernel_vsyscall() is
        push    %ebp
        movl    %ecx, %ebp
        syscall
        movl    $__USER32_DS, %ecx
        movl    %ecx, %ss
        movl    %ebp, %ecx
        popl    %ebp

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?