cvs commit: src/sys/kern kern_umtx.c src/sys/vm vm_fault.c vm_page.c vm_page.h vm_page2.h

[Matthew Dillon]

:While this doesn't seem like a very big hack, I still wonder how we could=
: do this more elegantly.  Essentially, the locking process should not los=
:e the physical page, I'd say.  The newly forked process may not use this =
:lock anyways.  How are other OSes dealing with this?  Or are they simply =
:disallowing futexes/umutexes for inter-process locking?
:
:cheers
:  simon

     I think we're kinda stuck.  If a threaded program fork()'s all of
     its memory must become copy-on-write to support the fork().  Both
     the mutex waiters and the signalers will still be pointing to the
     same memory, but it won't be the original memory. 

     The umtx_sleep() does ref the underlying page it sleeps on, the
     page doesn't go away.  But the problem is that the page becomes copy
     on write after the fork and any writers then modify a new page and
     not the original.  So a umtx_sleep() that goes to sleep before the
     fork() will be sleeping on the original backing page and not the
     copy (without the messy patch I committed).

     For umtx_sleep() we have a choice of sleeping on the virtual address 
     or sleeping on the physical address.  If we sleep on the virtual address
     copy-on-write doesn't effect it (there are other complications doing
     that but they can be solved).  But if we sleep on the virtual address
     then the calls cannot be used between non-threaded processes using
     shared memory.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>