From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen: arm: correct return value of raw_copy_to_guest_* Date: Fri, 06 Dec 2013 17:42:34 +0000 Message-ID: <52A20C8A.9020605@linaro.org> References: <1386343510-31974-1-git-send-email-ian.campbell@citrix.com> <52A1F4A1.5080201@linaro.org> <1386349428.25188.6.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1386349428.25188.6.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 12/06/2013 05:03 PM, Ian Campbell wrote: > On Fri, 2013-12-06 at 16:00 +0000, Julien Grall wrote: >> >> On 12/06/2013 03:25 PM, Ian Campbell wrote: >>> This is a generic interface which is supposed to return the number of bytes >>> which were not copied. Make it so and update the one incorrect caller. >> >> This is also the same for raw_clear_guest and raw_copy_from_guest. > > Oops, yes. > >> It seems the most of ARM code assume that these functions (or macro that >> call them) will return a negative value if it's fails. > > Hrm, the ones I looked at all seemed to match the return the number of > bytes not copied pattern (or more often just cared about 0 on success > and !0 otherwise). Did you find some which aren't that way? > copy_from_guest_offset is a macro which use raw_copy_from_guest. In xenmem_add_to_physmap_range (arch/arm/mm.c), we only check if the return is negative. -- Julien Grall