Re: Compat 32-bit syscall entry from 64-bit task!?

[Andrew Lutomirski]

On Thu, Jan 19, 2012 at 11:21 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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.

Unless you're writing a debugger and you want to disassemble the code
that's being executed (i.e. normal code, not a system call).  I wonder
how gdb guesses whether the cpu is in long mode.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/