Re: [PATCH] x86-64: simplify is32entry.S again

["H. Peter Anvin" <hpa@zytor.com>]

On 09/24/2010 05:35 AM, Jan Beulich wrote:
> Commits 36d001c70d8a0144ac1d038f6876c484849a74de and
> eefdca043e8391dcd719711716492063030b55ac fixed the same problem in two
> different, redundant of one another ways: Zero-extending the system
> call index from 32 to 64 bits and then doing comparison on the 64 bit
> register is just pointless.
> 
> Undo the second commit completely, as using REX prefixes where needed
> produces more efficient code than having an extra instruction in the
> stream (no matter how simple it is).
> 
> The first commit by itself also did quite a bit more than needed -
> comparison on the full 64-bit register is definitely unnecessary in
> all paths where the value is known to zero extended from 32 bits
> already (in one case this is even directly visible from the patch, as
> the zero extending instruction is the immediately preceding one). Undo
> those parts of the first commit too.

Yes, this optimizes the code slightly... it also removes any redundancy
in the protections which is part of why the bug could reappear in the
first place. Unless you have concrete numbers on system call entry
latency and that these longer instructions hurt, I *really don't* want that.

As Linus said, "the code was too subtle in the first place".

Furthermore, Roland was concerned about buggy ptrace users relying on
the zero-extension... if nothing else zero-extending in some paths and
not in others would open up for another instance of the same class of
problems (tested-is-not-what-is-executed).

So I'm going to NAK this patch unless provided with strong evidence that
the efficiency pays off.  Sorry.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.