From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: bug in xc_gntshr_munmap? Date: Fri, 26 Apr 2013 15:41:35 +0200 Message-ID: <517A840F.7060105@invisiblethingslab.com> References: <517A5FE7.9050904@invisiblethingslab.com> <1366983248.3142.100.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3076878986179160846==" Return-path: In-Reply-To: <1366983248.3142.100.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: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3076878986179160846== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7C9C43F257DBAF70DC02C38" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7C9C43F257DBAF70DC02C38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 mapp= ed by a >> * call to xc_gntshr_share_*. Never logs. >> */ >> int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t cou= nt); >> >> 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) a= lready >> 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? >=20 > 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 i= s 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. --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enigA7C9C43F257DBAF70DC02C38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJReoQPAAoJENuP0xzK19csCLQH/3SxN1cPlUugygx0HWAn06sd 3Z9iM4vWM6tVh5V+GaIPBNd4JyJywESpHzZGNYudJjprX7O5Z52zI8CZYBmDNl01 Gxwibx45cA6BdM6IjzFIYMOB8SQq2rse75U54Zq/LnY98qVe54vnAfnf+4oPqQtF LsMaxm9IY/rOajhA1pgSfhmyki0to9HVnIOOYYPz0oXOe5xSBfh9VI0rcsPkd3+n WctvnInsj7JCXkNriw2jZmjG3nAG3oGne28deXQAYDhoKnBbyjvqIRQ9Czj/ohhT obut370RfcppmYAEgSGGEwtLDAC40Tt8GEsZN6JntBTIpVC0spbpUZ4mQ3oojUE= =eezO -----END PGP SIGNATURE----- --------------enigA7C9C43F257DBAF70DC02C38-- --===============3076878986179160846== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3076878986179160846==--