summaryrefslogtreecommitdiffstats
path: root/sys/vm/vm_map.c
diff options
context:
space:
mode:
authoriedowse <iedowse@FreeBSD.org>2001-03-09 18:25:54 +0000
committeriedowse <iedowse@FreeBSD.org>2001-03-09 18:25:54 +0000
commit80d8e16746a7e6c767e69f1dd26ae918524229ad (patch)
tree1f256d86ecdfe876c294d6332c35a4cdc05665a5 /sys/vm/vm_map.c
parent5f61f8e47fe91c807dbc013e22e954c3cbc46586 (diff)
downloadFreeBSD-src-80d8e16746a7e6c767e69f1dd26ae918524229ad.zip
FreeBSD-src-80d8e16746a7e6c767e69f1dd26ae918524229ad.tar.gz
When creating a shadow vm_object in vmspace_fork(), only one
reference count was transferred to the new object, but both the new and the old map entries had pointers to the new object. Correct this by transferring the second reference. This fixes a panic that can occur when mmap(2) is used with the MAP_INHERIT flag. PR: i386/25603 Reviewed by: dillon, alc
Diffstat (limited to 'sys/vm/vm_map.c')
-rw-r--r--sys/vm/vm_map.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index 471e0af..e2e9f47 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -2155,6 +2155,10 @@ vmspace_fork(vm1)
&old_entry->offset,
atop(old_entry->end - old_entry->start));
old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
+ /* Transfer the second reference too. */
+ vm_object_reference(
+ old_entry->object.vm_object);
+ vm_object_deallocate(object);
object = old_entry->object.vm_object;
}
vm_object_clear_flag(object, OBJ_ONEMAPPING);
OpenPOWER on IntegriCloud