Date: Mon, 6 Sep 2004 01:39:31 -0400 From: Anish Mistry <mistry.7@osu.edu> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap Message-ID: <200409060139.39036.mistry.7@osu.edu> In-Reply-To: <20040905214625.GA952@green.homeunix.org> References: <200407271731.12282.mistry.7@osu.edu> <200409051315.25263.mistry.7@osu.edu> <20040905214625.GA952@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409060139.39036.mistry.7>