From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: Multicall result missing sign extension in Xen or Linux Date: Fri, 03 Aug 2012 15:26:03 -0400 Message-ID: <501C25CB.1000001@tycho.nsa.gov> References: <501C1F14.9000505@tycho.nsa.gov> <501C1FC5.40405@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <501C1FC5.40405@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jeremy Fitzhardinge Cc: Konrad Rzeszutek Wilk , xen-devel List-Id: xen-devel@lists.xenproject.org On 08/03/2012 03:00 PM, Jeremy Fitzhardinge wrote: > 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 > > There are hypercalls which will return a value that corresponds to a 32-bit error result - XENMEM_current_reservation, for example - but these are not likely to be called as part of a multicall. Most of the multicall users return zero, error, or a count. -- Daniel De Graaf National Security Agency