From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes Date: Mon, 28 Jan 2013 11:57:09 +0000 Message-ID: <51066795.5020306@citrix.com> References: <75aafcd809a7352a95a5.1359373484@andrewcoop.uk.xensource.com> <1359373846.6559.67.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1359373846.6559.67.camel@zakaz.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: Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 28/01/13 11:50, Ian Campbell wrote: > On Mon, 2013-01-28 at 11:44 +0000, Andrew Cooper wrote: >> To allow xenguest consumers to make use of the extra protection added as a >> result of xsa-25. >> >> Signed-off-by: Andrew Cooper >> >> --- >> Changes since v1: >> * Remove prototypes from xc_dom.h to remove duplication >> >> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xc_dom.h >> --- a/tools/libxc/xc_dom.h >> +++ b/tools/libxc/xc_dom.h >> @@ -209,10 +209,7 @@ int xc_dom_mem_init(struct xc_dom_image >> #endif >> >> int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz); >> -int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz); >> - >> int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz); >> -int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz); >> >> size_t xc_dom_check_gzip(xc_interface *xch, >> void *blob, size_t ziplen); >> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xenguest.h >> --- a/tools/libxc/xenguest.h >> +++ b/tools/libxc/xenguest.h >> @@ -177,6 +177,10 @@ int xc_dom_linux_build(xc_interface *xch >> unsigned int console_evtchn, >> unsigned long *console_mfn); >> >> +#define XENCTRL_HAS_DECOMPRESS_LIMITS >> +int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz); >> +int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz); > Looking at this a bit closer, do you know where a utility which only > includes xenguest.h is getting the necessary struct xc_dom_image * > handle from? None of the functions in xenguest.h seem to return it and > the only functions I can find which do are in xc_dom.h... > > This seems to be true for the two existing functions in xenguest.h which > take such a handle as well. > > The only in tree caller seems to be the Python bindings, and they just > include xc_dom.h. Is there some reason why the ocaml tools can't just do > this? > > Ian. > The immediate preceeding function, xc_dom_linux_build returns a struct xc_dom_image * as its second parameter, to allow the user of xenguest to manage the structure (in so far as it can be managed without the full declaration). ~Andrew