From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] tools/libxc: Don't leave scratch_pfn uninitialised if the domain has no memory Date: Thu, 29 Jan 2015 18:35:52 +0000 Message-ID: <54CA7D88.5050702@linaro.org> References: <1422460355-16163-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1422460355-16163-1-git-send-email-andrew.cooper3@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: Andrew Cooper , Xen-devel Cc: Wei Liu , Ian Jackson , Ian Campbell , Jan Beulich List-Id: xen-devel@lists.xenproject.org Hi Andrew, On 28/01/15 15:52, Andrew Cooper wrote: > c/s 5b5c40c0d1 "libxc: introduce a per architecture scratch pfn for temporary > grant mapping" accidentally an issue whereby there were two paths out of > xc_core_arch_get_scratch_gpfn() which returned 0, but only one of which > assigned a value to the gpfn parameter. > xc_domain_maximum_gpfn() can validly return 0, at which point gpfn 1 is a > valid scratch page to use. The original version was considering rc = 0 as an error. Should not we keep the same behavior? Regards, > In addition, widen rc before adding 1 and possibly overflowing. > > Signed-off-by: Andrew Cooper > CC: Julien Grall > CC: Jan Beulich > CC: Ian Campbell > CC: Ian Jackson > CC: Wei Liu > --- > tools/libxc/xc_core_x86.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/libxc/xc_core_x86.c b/tools/libxc/xc_core_x86.c > index fac99ec..d8846f1 100644 > --- a/tools/libxc/xc_core_x86.c > +++ b/tools/libxc/xc_core_x86.c > @@ -214,10 +214,10 @@ xc_core_arch_get_scratch_gpfn(xc_interface *xch, domid_t domid, > > rc = xc_domain_maximum_gpfn(xch, domid); > > - if ( rc <= 0 ) > + if ( rc < 0 ) > return rc; > > - *gpfn = rc + 1; > + *gpfn = (xen_pfn_t)rc + 1; > > return 0; > } > -- Julien Grall