Linus Torvalds wrote: > On Thu, Jan 19, 2012 at 8:01 AM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote: > > Andrew Lutomirski wrote: > >> It's reasonable, obvious, and even more wrong than it appears. On > >> Xen, there's an extra 64-bit GDT entry, and it gets used by default. > >> (I got bitten by this in some iteration of the vsyscall emulation > >> patches -- see user_64bit_mode for the correct and > >> unusable-from-user-mode way to do this.) > > > > Here it is: > > > > static inline bool user_64bit_mode(struct pt_regs *regs) > > This is pointless, even if it worked, which it clearly doesn't on Xen > (or other random situations). > > Why would you care? > > The issue is *not* whether somebody is running in 32-bit mode or 64-bit mode. > > The problem is the system call itself, and that can be 32-bit or > 64-bit independently of the execution mode. So knowing the user-mode > mode is simply not relevant. Sorry, you're responding to a different question than the one I was talking about. My bad for adding to the confusion. Mine was: strace currently checks the CS value and may have a bug on existing/older kernels if Xen is involved when using the *normal* syscall entry point (not int $0x80). Can we patch strace to solve that on those kernels in a generic way, or does the fix need to hard-code knowledge of Xen's CS values (and any similar PV hypervisors if there are any). No amount of patching newer kernels will fix that, but it would be nice if newer kernels made it unambiguous. You've usefully pointed out that there's no reliable way to tell if the tracee is executing in long mode. If we're adding pseudo-flags to say what kind of syscall it is, it would be no bad thing to have a pseudo-flag to say if userspace is in long mode -- made available to breakpoints and single-stepping as well. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
