From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:37:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C8716A4CE; Mon, 6 Sep 2004 05:37:37 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7159843D55; Mon, 6 Sep 2004 05:37:36 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i865O8jr023622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 01:24:09 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Brian Fundakowski Feldman Date: Mon, 6 Sep 2004 01:39:31 -0400 User-Agent: KMail/1.6.2 References: <200407271731.12282.mistry.7@osu.edu> <200409051315.25263.mistry.7@osu.edu> <20040905214625.GA952@green.homeunix.org> In-Reply-To: <20040905214625.GA952@green.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_bg/OBch9/Cld1Au"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409060139.39036.mistry.7@osu.edu> X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_42, PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 05:37:37 -0000 --Boundary-02=_bg/OBch9/Cld1Au Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 05 September 2004 05:46 pm, you wrote: > On Sun, Sep 05, 2004 at 01:15:15PM -0400, Anish Mistry wrote: > > On Sunday 29 August 2004 12:59 am, you wrote: > > > On Tue, Aug 10, 2004 at 01:53:14PM -0400, Anish Mistry wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > On Wednesday 04 August 2004 06:39 pm, you wrote: > > > > > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > > > > > Ok, so we need something like vm_map_findspace(), but for proce= ss > > > > > > address mapping? ie. pmap_findspace() that will return an > > > > > > address to a large enough free chunk? > > > > > > > > > > That's a good start, just to get something to work with. How this > > > > > fits in with the vm code and whether it is ultimately suitable in > > > > > the long run is probably up to Alan Cox. For now, just get > > > > > something that (a) doesn't break anything else; and (b) lets Wine > > > > > behave the way it needs to. > > > > > > > > > > AFAIK, there are still pthread issues with Wine, but those can't = be > > > > > addressed until the mmap issue has a work-around. > > > > > > > > I've got a small patch that gets by the initial problem about not > > > > being to mmap the memory for the libraries, but the addresses that > > > > are mmap'ed seem to seem to overlap with memory that the current > > > > pthread implementation want to mmap for the "red zone" when wine > > > > tries to create a thread. It can't mmap the "red zone" addresses > > > > since all those address mapping where gobbled up before the thread > > > > launched. > > > > I'll try to figure out a way to maybe leave a space for the "red > > > > zone" and see if that works. > > > > Someone who actually knows what they are doing should probably take= a > > > > look. > > > > > > The red pages are implemented by leaving the memory space unallocated; > > > I don't like that one bit -- this will cause those spaces to be > > > allocated but given no protection, which should provide the crash > > > feature that the guard pages are there for, but be less bogus (and it > > > doesn't use more "memory," but it will use a few more vm_map_entrys. > > > > > > Index: lib/libpthread/thread/thr_stack.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v > > > retrieving revision 1.8 > > > diff -u -r1.8 thr_stack.c > > > --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 > > > +++ lib/libpthread/thread/thr_stack.c 29 Aug 2004 04:50:28 -0000 > > > @@ -214,6 +214,17 @@ > > > stacksize, PROT_READ | PROT_WRITE, MAP_STACK, > > > -1, 0)) =3D=3D MAP_FAILED) > > > attr->stackaddr_attr =3D NULL; > > > + if (attr->stackaddr_attr !=3D NULL) { > > > + void *red; > > > + > > > + red =3D mmap((char *)attr->stackaddr_attr + stacksize, > > > + _thr_guard_default, PROT_NONE, > > > + MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0); > > > + if (red =3D=3D MAP_FAILED) { > > > + (void)munmap(attr->stackaddr_attr, stacksize); > > > + attr->stackaddr_attr =3D NULL; > > > + } > > > + } > > > } > > > if (attr->stackaddr_attr !=3D NULL) > > > return (0); > > > > This is good. Can this be committed? > > Probably; can you verify it fixes the problem as you observe it? Hmmm...well I can't seem to reproduce this problem anymore with my latest=20 cvsup Saturday night, so I guess this doesn't need to be committed. =2D-=20 Anish Mistry --Boundary-02=_bg/OBch9/Cld1Au Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBO/gaxqA5ziudZT0RAoDrAJ9C0kZk2XJ/pDLeY/qNZCGPLQPOyQCfUhQd MR6t9mOqBmJmVEmn/oVL1ac= =hCG3 -----END PGP SIGNATURE----- --Boundary-02=_bg/OBch9/Cld1Au--