Re: [Xen-devel] bug in xc_gntshr_munmap?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-04-26 at 14:41 +0100, Marek Marczykowski wrote:
> On 26.04.2013 15:34, Ian Campbell wrote:
> > On Fri, 2013-04-26 at 12:07 +0100, Marek Marczykowski wrote:
> >> Hi,
> >>
> >> Header says:
> >> /*
> >>  * Unmaps the @count pages starting at @start_address, which were mapped 
> >> by a
> >>  * call to xc_gntshr_share_*. Never logs.
> >>  */
> >> int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count);
> >>
> >> But implementation calls:
> >> static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h,
> >>                                void *start_address, uint32_t count)
> >> {
> >>     return munmap(start_address, count);
> >> }
> >>
> >> munmap(2) expect second argument to be size of mapped area (in bytes), not
> >> pages count.
> >>
> >> Users of xc_gntshr_munmap (the only one I'm aware of is libxenvchan) 
> >> already
> >> uses that broken semantic.
> >>
> >> Is it going to be fixed (I can send trivial patch for both libxc and
> >> libxenvchan), or the comment in header should be updated?
> > 
> > I think the function should behave the same as the map side, whichever
> > that is.
> 
> Map side uses pages count.
> Also xc_gnttab_{grant_map,munmap} both uses pages count. So I assume it is a
> bug. The question is can it be simply changed - some software can already
> depend on that broken semantic...

libxc does not provide a stable API/ABI so it is OK to change as long as
you update the intree callers. We'll bump the SONAMEs before release if
we haven't already this cycle...


> Anyway I will send a patch in a moment.
> 



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