[lkml]   [2011]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)
On Tue, Aug 23, 2011 at 12:03 PM, Linus Torvalds
<> wrote:
> On Mon, Aug 22, 2011 at 11:15 PM, Al Viro <> wrote:
>> * it does SETREGS, setting eax to return value, eip to original return
>> address of syscall insn... and ebp to what it had in regs.bp.  I.e. the
>> damn arg6 value.
> Ok, I think that exhaustively explains that
>  (a) our system call restart has always worked correctly, and we're good.
>  (b) it's simply just UML that is buggy, and doesn't understand the
> subtleties about doing GETREGS at a system call.
> and I think that the correct and simple solution is to just teach UML
> to understand the proper logic of pt_regs during a system call (and a
> 'syscall' instruction in particular).
> The thing is, UML emulates 'syscall' the way the *CPU* does it, not
> the way *we* do it. That may make sense, but it's simply not correct.
> So I would vote very strongly against actually changing anything in
> arch/x86. This is very much an UML issue.
> Suggested fixes:
>  - instead of blindly doing SETREGS, just write the result registers
> individually like you suggested
> OR (and perhaps preferably):
>  - teach UML that when you do 'GETREGS' after a system call trapped,
> we have switched things around to match the "official system call
> order", and UML should just undo our swizzling, and do a "regs.ebp =
> regs.ecx" to make it be what the actual original registers were (or
> whatever the actual correct swizzle is - I didn't think that through
> very much).
> IOW, I think the core kernel does the right thing. Our argument
> register swizzling is odd, yes, but it's an implementation detail that
> something like uml should just have to take into account. No?
> Hmm?

Egads. Does this mean that doing GETREGS and then doing SETREGS later
on with the *exact same values* is considered incorrect? IMO, this
way lies madness.

In any case, this seems insanely overcomplicated. I'd be less afraid
of something like my approach (which, I think, makes all of the
SYSCALL weirdness pretty much transparent to ptrace users) or of just
removing SYSCALL entirely from 32-bit code.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-08-23 18:16    [W:0.147 / U:1.896 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site