When using a debug kernel fusefs causes a panic shortly after a filesystem has
been mounted.
The stack looks like this:

> $C
000002a1004fae41 vpanic(1102858, 1102a58, 70134350, 2a1004fbca0, 2a1004fbca0, 0
)
000002a1004faef1 fuse_global_fini+0x14(5, 7b35a808, 4, 1, 40, 18811e4)
000002a1004fafa1 fuse`_fini+0x20(130bd40, 7b34d030, 0, 188ac00, 1, 0)
000002a1004fb061 moduninstall+0x204(300118c9970, 1, 1, 18db400, 130bd10, 
7b34d030)
000002a1004fb111 mod_uninstall_all+0x70(10e, 180c000, f3, 300118c9970, 0, 
18d5400)
000002a1004fb1c1 mod_uninstall_daemon+0x1d4(3c, 18d7e20, 2a1004fba88, 130bd88, 
188ad90, fffffffffc6c793c)
000002a1004fb291 thread_start+4(0, 0, 0, 0, 0, 0)


This happens when a DEBUG kernel is being used as it will periodically (every
60 seconds) attempt to unload all modules on the system. The problematic code
is:

82 int
83 _fini(void)
84 {
85     cmn_err(CE_NOTE, "Inside module_fini");
86     fuse_global_fini();
87     return (mod_remove(&ml));
88 }

The global state (currently just a single mutex) is being free'ed/destroyed
before mod_remove() is called. If mod_remove() fails - for example if a
filesystem is still mounted, the _fini() routine will be called again at a
later time to remove the module. When this is called a second time the
mutex_destroy() will be called a second time which will result in the above
panic.
Global state should only be free'ed if mod_remove() succeeds first.