Re: [Xen-devel] [PATCH] linux_gntshr_munmap: munmap takes a length, not a page count

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-09-03 at 15:21 +0100, David Vrabel wrote:
> On 03/09/14 15:17, Ian Campbell wrote:
> > On Wed, 2014-09-03 at 15:15 +0100, David Vrabel wrote:
> >> On 03/09/14 15:01, Ian Campbell wrote:
> >>> On Mon, 2014-09-01 at 13:16 +0100, David Scott wrote:
> >>>> This fixes a bug where if a client shares more than 1 page, the
> >>>> munmap call fails to clean up everything. A process which does
> >>>> a lot of sharing and unsharing can run out of resources.
> >>>
> >>> The doc comment on xc_gntshr_munmap does say count is in pages, so your
> >>> change is correct but all of the in tree callers seem to pass a number
> >>> of bytes not a number of pages. i.e. everything in tools/libvchan passes
> >>> n*PAGE_SIZE.
> >>>
> >>> So I don't think this change is complete without also updating those.
> >>
> >> Would the corrent non-ABI/API-breaking fix be to just update the
> >> documentation?
> > 
> > libxc doesn't have a stable API or ABI.
> 
> xc_gntshr_*() really should be part of a separate libxc-for-domu that
> does have a stable ABI.

This hadn't occurred to me, but yes, this does sound sensible.

>   But since it isn't yet...
> 
> > My thinking in this case was that @count being pages was consistent with
> > other related functions in the API and also avoids issues of what to do
> > if count%4096 != 0.
> 
> ...this sounds reasonable.

Thanks.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel