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

[Daniel Eischen]

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.

-- 
Dan Eischen