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

[Roland McGrath]

On Wed, Jan 18, 2012 at 1:21 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> Roland, could you refresh my memory what your objection to this was?

Sorry, I don't really recall.  I could dig through old email archives, but
they'd be archives of messages I sent to you, so you should have them too.

The only principle in this area I recall having an opinion about is that
we should not mix up things that are bona fide user-visible state with
things that aren't.  (By "user-visible" I mean things that the task in
question can see or affect by just doing normal instructions, as opposed
to things only controlled via ptrace, such as the debug registers.)  But
that principle is not really being violated here.

I recall that you and I discussed making the path-of-entry visible somehow
and I was in favor of doing that.  As I recall it, we just never bothered
to follow through.

There are all the concerns about obscure ABI compatibility with
expectations of existing debuggers and so forth, which Linus has mentioned.
For that I can accept his point that things today so mishandle the
int80-from-64 case that something like a new meaning for high bits of
orig_ax or whatnot in just that case would not be actually problematic.
When you and I were discussing a more general feature of distinguishing
int80 from sysenter from syscall from traps from asynchronous interrupts,
that was of more concern.

I do feel strongly that any new means of exposing bona fide user state
ought to be done via the user_regset mechanism.  (i.e., either overloading
some existing user_regs_struct bits if that truly is harmless to
compatibility, or adding a new regset flavor.)  That way it is
automatically recorded in core files, accessible with PTRACE_GETREGSET,
etc.  (But I'm not really working on this stuff any more, so I'm out of the
business of arguing strenuously about such opinions.)


Thanks,
Roland
--
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/