In D4146#87206, @cem wrote:

Looks good to me.

Did you tested the patch, in particular, with your failpoints ?

I've tested the proposed patch with some failpoints (described in https://reviews.freebsd.org/D4103 ) and it seems to fix this particular panic. There are still some bugs left in this area.

(1) We can still hit this related but slightly different panic with the UMA NOWAIT failpoints + while true; do sh -c "echo | cat | cat > /dev/null"; done:

panic @ time 1448702920.309, thread 0xfffff80028b93000: backing_object 0xfffff800282fd400 was somehow re-referenced during collapse!
cpuid = 0
Panic occurred in module kernel loaded at 0xffffffff80200000:

Stack: --------------------------------------------------
kernel:kassert_panic+0x17e
kernel:vm_object_collapse+0x40d
kernel:vm_object_deallocate+0x4c2
kernel:vm_map_process_deferred+0x88
kernel:vm_map_remove+0xca
kernel:vmspace_exit+0xcc
kernel:exit1+0x55d
kernel:sys_sys_exit+0xd
kernel:amd64_syscall+0x2f6
--------------------------------------------------
Disabling swatchdog
Cannot dump stacks. No stack dump device defined.

db> show object 0xfffff800282fd400
Object 0xfffff800282fd400: type=0, size=0x20, res=0, ref=2, flags=0x1008 ruid 0 charge 20000
 sref=1, backing_object(0)=(0)+0x0

And (2), the D4103 failpoints still cause userspace processes to dump core. But the kernel stays up with just the D4103 failpoints.

In D4146#90570, @cem wrote:

I've tested the proposed patch with some failpoints (described in https://reviews.freebsd.org/D4103 ) and it seems to fix this particular panic. There are still some bugs left in this area.

(1) We can still hit this related but slightly different panic with the UMA NOWAIT failpoints + while true; do sh -c "echo | cat | cat > /dev/null"; done:

panic @ time 1448702920.309, thread 0xfffff80028b93000: backing_object 0xfffff800282fd400 was somehow re-referenced during collapse!
cpuid = 0
Panic occurred in module kernel loaded at 0xffffffff80200000:

Stack: --------------------------------------------------
kernel:kassert_panic+0x17e
kernel:vm_object_collapse+0x40d
kernel:vm_object_deallocate+0x4c2
kernel:vm_map_process_deferred+0x88
kernel:vm_map_remove+0xca
kernel:vmspace_exit+0xcc
kernel:exit1+0x55d
kernel:sys_sys_exit+0xd
kernel:amd64_syscall+0x2f6
--------------------------------------------------
Disabling swatchdog
Cannot dump stacks. No stack dump device defined.

db> show object 0xfffff800282fd400
Object 0xfffff800282fd400: type=0, size=0x20, res=0, ref=2, flags=0x1008 ruid 0 charge 20000
 sref=1, backing_object(0)=(0)+0x0

I think an easy way to understand what is going on is to add the debugging print like

if ((object->flags & OBJ_IN_COLLAPSE) != 0) {printf("referencing the backing collapsed obj %p\n", object); kdb_backtrace();}

and correspondingly set and clear the new OBJ_IN_COLLAPSE flag for the backing_object in the vm_object_collapse().

I suspect that this happens during some walk of the shadow chain which walk increases the ref count. Might be, even during the vm_fault(). Most likely, the assert is simply invalid and would need to be removed, but lets see when it is triggered.

And (2), the D4103 failpoints still cause userspace processes to dump core. But the kernel stays up with just the D4103 failpoints.

Ok, lets finish with the assert first. I want to flush this patch before producing more changes.

In D4146#90770, @kib wrote:

I think an easy way to understand what is going on is to add the debugging print like

if ((object->flags & OBJ_IN_COLLAPSE) != 0) {printf("referencing the backing collapsed obj %p\n", object); kdb_backtrace();}

and correspondingly set and clear the new OBJ_IN_COLLAPSE flag for the backing_object in the vm_object_collapse().

I suspect that this happens during some walk of the shadow chain which walk increases the ref count. Might be, even during the vm_fault(). Most likely, the assert is simply invalid and would need to be removed, but lets see when it is triggered.

Unfortunately, adding such checking seems to have closed the race.