Re: Anyone able to verify the fix for (was Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.)
: :I'll remove (or change) the assertion later this evening :unless I hear protests to the contrary. : :Alan : Sounds like a plan. When you get it committed I'll bring it up on one of my test boxes and run it through the gauntlet. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone able to verify the fix for (was Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.)
I'll remove (or change) the assertion later this evening unless I hear protests to the contrary. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone able to verify the fix for (was Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.)
: :This patch introduces a new bug. While it does guarantee that :the assertion in vm_object_shadow isn't tripped over, it doesn't :clear the OBJ_ONEMAPPING flag on the newly created shadow object. :(New objects are created with OBJ_ONEMAPPING set.) Consequently, :we'll have two overlapping mappings to the same shadow object :that has OBJ_ONEMAPPING set. That's bad. : :Alan Ach. I'll just clear in both places. I really don't have time to go through the code and 'do it right', but if someone else wants to I'll be happy to review their code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone able to verify the fix for (was Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.)
This patch introduces a new bug. While it does guarantee that the assertion in vm_object_shadow isn't tripped over, it doesn't clear the OBJ_ONEMAPPING flag on the newly created shadow object. (New objects are created with OBJ_ONEMAPPING set.) Consequently, we'll have two overlapping mappings to the same shadow object that has OBJ_ONEMAPPING set. That's bad. The real problem is that the assertion is just plain wrong, not the code around it. It needs to be corrected or removed. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Anyone able to verify the fix for (was Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.)
Has Brian or Michael or anyone been able to verify whether my patch
below fixes the reported vm_object_shadow panics yet? I'd like to get
it committed (or scrapped).
-Matt
Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.187
diff -u -r1.187 vm_map.c
--- vm_map.c2000/02/28 04:10:35 1.187
+++ vm_map.c2000/04/15 18:02:06
@@ -2119,10 +2119,14 @@
}
/*
-* Add the reference before calling vm_object_shadow
-* to insure that a shadow object is created.
+* Clear OBJ_ONEMAPPING before calling vm_object_shadow
+* to ensure that a shadow object is created. Add a
+* reference to cover the new vm_map_entry being
+* associated with the object.
*/
vm_object_reference(object);
+ vm_object_clear_flag(object, OBJ_ONEMAPPING);
+
if (old_entry->eflags & MAP_ENTRY_NEEDS_COPY) {
vm_object_shadow(&old_entry->object.vm_object,
&old_entry->offset,
@@ -2130,7 +2134,6 @@
old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
object = old_entry->object.vm_object;
}
- vm_object_clear_flag(object, OBJ_ONEMAPPING);
/*
* Clone the entry, referencing the shared object.
Index: vm_object.c
===
RCS file: /home/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.171.2.1
diff -u -r1.171.2.1 vm_object.c
--- vm_object.c 2000/03/17 10:47:35 1.171.2.1
+++ vm_object.c 2000/04/15 18:13:58
@@ -900,7 +900,13 @@
source = *object;
/*
-* Don't create the new object if the old object isn't shared.
+* If the old object is not shared we may be able to simply use it
+* as the shadow rather then have to create a new object. Only
+* objects that we can guarentee this case can be optimized - that is,
+* only objects with no handles that other processes can get a hold
+* of which are otherwise unassociated, have only one mapping, and
+* only one reference count. XXX do we need the reference count check
+* any more? XXX
*/
if (source != NULL &&
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
