Change Details

If fault started before vmspace_fork() locked the map, and then during fork, vm_map_copy_entry()->vm_object_split() is executed, it is possible that the fault instantiate the page into the original object when the page was already copied into the new object (see vm_map_split() for the orig/new objects terminology). This can happen if split found a busy page (e.g. from the fault) and slept dropping the objects lock. Handle this by: - checking that there is no page at the index, if there is, we can ignore the additional page in the original object. - bumping the timestamp of the map before calling split. This forces the fault handlers to try to lock the map and to retry fault handling. The later is needed to ensure that proper page from the new object is installed into the MMU tables. Otherwise userspace might see older incorrect copy.

If fault started before vmspace_fork() locked the map, and then during fork, vm_map_copy_entry()->vm_object_split() is executed, it is possible that the fault instantiate the page into the original object when the page was already copied into the new object (see vm_map_split() for the orig/new objects terminology). This can happen if split found a busy page (e.g. from the fault) and slept dropping the objects lock. Handle this by checking that there is no page at the index, if there is, we can ignore the additional page in the original object. Note that vmspace_fork() already bumped the timestamp of the map before calling split. This forces the fault handlers to try to lock the map and to retry fault handling. The later is needed to ensure that proper page from the new object is installed into the MMU tables. Otherwise userspace might see older incorrect copy.

If fault started before vmspace_fork() locked the map, and then during fork, vm_map_copy_entry()->vm_object_split() is executed, it is possible that the fault instantiate the page into the original object when the page was already copied into the new object (see vm_map_split() for the orig/new objects terminology). This can happen if split found a busy page (e.g. from the fault) and slept dropping the objects lock. Handle this by: - checking that there is no page at the index, if there is, we can ignore the additional page in the original object. - Note that vmspace_fork() already bumpinged the timestamp of the map before calling split. This forces the fault handlers to try to lock the map and to retry fault handling. The later is needed to ensure that proper page from the new object is installed into the MMU tables. Otherwise userspace might see older incorrect copy.