Re: Multicall result missing sign extension in Xen or Linux

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 08/03/2012 11:57 AM, Daniel De Graaf wrote:
> While trying to figure out why a failing component of a multicall did not
> properly return its result, I discovered that multicall results are not
> sign-extended when placed in the unsigned long result field. For hypercalls
> such as do_mmu_update which return a (signed) int, this results in Linux
> incorrectly thinking the hypercall succeeded when it has actually failed
> since arch/x86/xen/multicalls.c uses a signed long for "result" and checks
> (b->entries[i].result < 0).
>
> Is this a bug in Xen (using the wrong return type for do_mmu_op and other
> hypercalls) or in Linux (assuming all returns are signed longs)? One or the
> other needs to be changed, because the current setup is silently hiding
> failed memory mapping operations.
>

Ah, that explains a long-standing mystery for me that I never got around
to investigating.

If Xen is populating a 64-bit result with non-signed-extended 32-bit
result, then it sounds like a Xen bug, but one that's effectively baked
into the ABI now.  Is there any risk of the unextended 32bit error being
ambiguously confused with a legitimate result?

    J