[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.063 / U:1.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site