Losing pages from a mmap in threaded app vs. non-threaded

[Sean McNeil]

OK, would this happen to be 8 pages typically?

On Wed, 2003-11-19 at 13:24, Daniel Eischen wrote:
> On Wed, 19 Nov 2003, Sean McNeil wrote:
> 
> > Hello all,
> > 
> > I have an interesting problem.  I've ported a device driver to FreeBSD
> > from Linux and all works just fine with the non-threaded application. 
> > When I use threads, the first 8 pages of the map get removed from the
> > process vmspace.
> > 
> > A trick is used to mmap different memory pools of the driver.  There are
> > 3 of them and an offset is given to mmap to identify which one:
> > 
> > 0x10000000
> > 0x20000000
> > 0x40000000
> > 
> > The buffer I see losing the first 8 pages is the one mmap'd with
> > 
> > 0x40000000
> > 
> > I haven't looked into the other mmaps, as the above one is the most
> > important.  mmap is called correctly and each page is returned
> > appropriately.  Again, this works without threads.
> > 
> > Is there some mmap region that threads uses that is conflicting with my
> > choice?  Is there any known issue with mmap and threads?  This problem
> > happens with libc_r.so, libkse.so, and libthr.so.
> > 
> > The work I'm doing is split into driver/application and turnaround is
> > high to get the application people to recompile with different values
> > (in progress), so I thought asking here might answer my question sooner
> > than experimentation.
> > 
> > All comments/replies are greatly appreciated,
> > Sean
> 
> The thread libraries use mmap to map kern.usrstack as
> thread stacks and guard pages.  I don't know how this
> would affect your driver.