[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Multicall result missing sign extension in Xen or Linux


  • To: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Fri, 03 Aug 2012 22:26:29 +0100
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • Delivery-date: Fri, 03 Aug 2012 21:26:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac1xvqUGha5Adwpvl0iBvvSGCuu10g==
  • Thread-topic: [Xen-devel] Multicall result missing sign extension in Xen or Linux

On 03/08/2012 19:57, "Daniel De Graaf" <dgdegra@xxxxxxxxxxxxx> 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.

I think this is a Xen bug, and we should update all hypercalls to explicitly
return a long. Nice and straightforward.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.