[mistry.7@osu.edu: Re: FreeBSD and wine mmap]

Brian Fundakowski Feldman green at FreeBSD.org
Wed Sep 8 10:49:44 PDT 2004


I don't think that any allocated "red zones" should be left empty --
they should be explicitly allocated with no protection so that actually
free memory space can be explicitly searched for.  Comments?

----- Forwarded message from Anish Mistry <mistry.7 at osu.edu> -----

From: Anish Mistry <mistry.7 at osu.edu>
To: Brian Fundakowski Feldman <green at freebsd.org>
Subject: Re: FreeBSD and wine mmap
Date: Sun, 5 Sep 2004 13:15:15 -0400
Cc: freebsd-current at freebsd.org

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 process
> > > > 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
> ===================================================================
> 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)) == MAP_FAILED)
>     attr->stackaddr_attr = NULL;
> +  if (attr->stackaddr_attr != NULL) {
> +   void *red;
> +
> +   red = mmap((char *)attr->stackaddr_attr + stacksize,
> +       _thr_guard_default, PROT_NONE,
> +       MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0);
> +   if (red == MAP_FAILED) {
> +    (void)munmap(attr->stackaddr_attr, stacksize);
> +    attr->stackaddr_attr = NULL;
> +   }
> +  }
>   }
>   if (attr->stackaddr_attr != NULL)
>    return (0);
This is good.  Can this be committed?
-- 
Anish Mistry



----- End forwarded message -----

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\


More information about the freebsd-threads mailing list