From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: REGRESSION [PATCH v2 08/13] libxc: Check xc_domain_maximum_gpfn for negative return values Date: Fri, 27 Mar 2015 10:14:47 -0400 Message-ID: <20150327141446.GF22791@l.oracle.com> References: <1426783678.21742.75.camel@citrix.com> <20150319185416.GC21217@x230.dumpdata.com> <1426844888.21742.107.camel@citrix.com> <20150320143434.GD17267@l.oracle.com> <20150320144925.GA22093@l.oracle.com> <1426863624.21742.213.camel@citrix.com> <20150320154555.GD2085@l.oracle.com> <1426870986.21742.226.camel@citrix.com> <551474F9.5060705@citrix.com> <1427453527.13935.108.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YbV2G-00078H-36 for xen-devel@lists.xenproject.org; Fri, 27 Mar 2015 14:14:56 +0000 Content-Disposition: inline In-Reply-To: <1427453527.13935.108.camel@citrix.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: Andrew Cooper , ian.jackson@eu.citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Fri, Mar 27, 2015 at 10:52:07AM +0000, Ian Campbell wrote: > On Thu, 2015-03-26 at 21:07 +0000, Andrew Cooper wrote: > > On 20/03/15 17:03, Ian Campbell wrote: > > > On Fri, 2015-03-20 at 11:45 -0400, Konrad Rzeszutek Wilk wrote: > > >> From 45bd7cd377b0b8364757cc2bc0bd8d6a13523a97 Mon Sep 17 00:00:00 2001 > > >> From: Konrad Rzeszutek Wilk > > >> Date: Fri, 13 Mar 2015 14:57:44 -0400 > > >> Subject: [PATCH] libxc: Check xc_domain_maximum_gpfn for negative return > > >> values > > >> > > >> Instead of assuming everything is always OK. We stash > > >> the gpfns value as an parameter. Since we use it in three > > >> of places we might as well update xc_domain_maximum_gpfn > > >> to do the right thing. > > >> > > >> Suggested-by: Ian Campbell > > >> Signed-off-by: Konrad Rzeszutek Wilk > > > Acked + applied along with the rest of the series, thanks, > > > > This change as unfortunately causes a regression in migration v2, > > because the fenceposting has changed and the function no longer returns > > the maximum gpfn. It returns one past the maximum gpfn. > > Oops, so it does, I noticed that but didn't fully think through the > naming implications once I noticed all the callers being correctly > adjusted, sorry. > > > It would appear that migration v2 was the only consumer which actually > > want the max gpfn. > > > > Can we either rename the function to accurately name the value it > > returns (although I am out of ideas as to what this might be), or undo > > the fenceposting change so that it continues to return the value it > > claims to return. > > Putting the fence posting back, which will involve adjusting the other > callers, is probably best and reflects the underlying hypercall. > > I think maximum_gpfn+1 could be described as nr_gpfns if we wanted to go > the renaming route, or make a wrapper which did the +1, returning the > original to the expect semantics. > > Konrad, will you take care of this one way or another? Yes. I will just add an xc_nr_gpfns and conver the in-tree callers to use that. And naturally revert the xc_domain_maximum_gpfn. Andrew, thank you for noticing this! > > Ian. >