Re: bug in xc_gntshr_munmap?

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1375 bytes --]

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...

Anyway I will send a patch in a moment.

-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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