On Tue, Aug 23, 2011 at 12:03 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Aug 22, 2011 at 11:15 PM, Al Viro <v...@zeniv.linux.org.uk> 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. --Andy ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
