From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 04:28:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5938C1065670 for ; Wed, 11 Apr 2012 04:28:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CDFAE8FC14 for ; Wed, 11 Apr 2012 04:28:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3B4Sb0e060389; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3B4SbYn000280; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3B4SbAi000279; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 07:28:37 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120411042837.GD2358@deviant.kiev.zoral.com.ua> References: <20120410095726.GU2358@deviant.kiev.zoral.com.ua> <1334108024.348.YahooMailClassic@web180005.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wmY+ywD75ArFSrfn" Content-Disposition: inline In-Reply-To: <1334108024.348.YahooMailClassic@web180005.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:28:43 -0000 --wmY+ywD75ArFSrfn Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 06:33:44PM -0700, Sushanth Rai wrote: >=20 > > > I don't know if that has anything to do with failure. > > The snippet of code that returns failure in vm_fault() is > > the following: > > >=20 > > > if (fs.pindex >=3D fs.object->size) { > > >=9A =9A > > =9A=9A=9Aunlock_and_deallocate(&fs); > > >=9A =9A =9A=9A=9Areturn > > (KERN_PROTECTION_FAILURE); > > > } > > >=20 > > > Any help would be appreciated. > >=20 > > This might be a bug fixed in r191810, but I am not sure. > >=20 >=20 > I tried that fix but it didn't work. What seems to happen is that libm is= mmap'ed beyond the size of the file. From truss o/p, I see the following: >=20 > open("/lib/libm.so.5",O_RDONLY,030577200) =3D 3 (0x3) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D918533,size=3D115560,blksize=3D4096 = }) =3D 0 (0x0) > read(3,"\^?ELF\^B\^A\^A\t\0\0\0\0\0\0\0"...,4096) =3D 4096 (0x1000) > mmap(0x0,1155072,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) =3D 34= 366242816 (0x800634000) >=20 > So the size of the file is 115560 but mmap() length is 1155072. The memor= y map of the file corresponding to libm as seen from running 'cat /proc//map' is the following: >=20 > 0x800634000 0x80064c000 24 0 0xffffff002553eca8 r-x 108 54 0x0 COW NC vno= de /lib/libm.so.5 > 0x80064c000 0x80064d000 1 0 0xffffff01d79b0a20 r-x 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 > 0x80064d000 0x80074c000 3 0 0xffffff002553eca8 r-x 108 54 0x0 COW NC vnod= e /lib/libm.so.5 > 0x80074c000 0x80074e000 2 0 0xffffff01d79f1288 rw- 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 >=20 >=20 > when the program tries to fault-in all the pages as part of call to mlock= all(), the following check in vm_fault() fails when trying to fault-in 0x80= 0651000. >=20 > if (fs.pindex >=3D fs.object->size) { > unlock_and_deallocate(&fs); > return (KERN_PROTECTION_FAILURE); > } >=20 > since the object size corresponds to size of libm and fault address is on= e page beyond the object size. Is this a bug ? Then it should be fixed in r190885. Could you use something less antique, please ? --wmY+ywD75ArFSrfn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FCHUACgkQC3+MBN1Mb4ji0QCfYZ9D9iptL5BNKYa1pyOoNYgt dpoAnR/NGj9SfNW2VrQ2d42QnIFLVJIT =Taew -----END PGP SIGNATURE----- --wmY+ywD75ArFSrfn--