Ugh. Since it may call kmem_malloc(), UMA must hold Giant.

This is the same problem the mbuf system has, and its what's
keeping network device drivers under Giant in 5.0.

Both subsytems should probably have GIANT_REQUIRED at all entry
points so as to catch locking problems like this earlier.


Kris Kennaway writes:
 > I think this is the same one I reported a few days ago (another alpha
 > under heavy load).
 > panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312
 > db_print_backtrace() at db_print_backtrace+0x18
 > panic() at panic+0x104
 > _mtx_assert() at _mtx_assert+0xb4
 > kmem_malloc() at kmem_malloc+0x50
 > page_alloc() at page_alloc+0x3c
 > uma_large_malloc() at uma_large_malloc+0x58
 > malloc() at malloc+0x10c
 > fdalloc() at fdalloc+0x1b0
 > do_dup() at do_dup+0x1a4
 > dup2() at dup2+0x24
 > syscall() at syscall+0x338
 > XentSys() at XentSys+0x64
 > --- syscall (90) ---
 > --- user mode ---
 > panic
 > Kris

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to