As with others on the list, I've been getting a lot of witness complaints:
../../../vm/uma_core.c:1327: could sleep with "process lock" locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with "process lock" locked from ../../../kern/kern_prot.c:613 Basically, every time cron runs, it does a setuid() or seteuid(), which calls change_ruid or change_euid which call uifree and uifind (which does the malloc with M_WAITOK while holding PROC_LOCK). kern/kern_resource.c:862 uifind() attempts to avoid sleeping with the hash table mutex by unlocking it, mallocing a new uidinfo, then locking it again and checking that another thread didn't create the same uidinfo while it was asleep. However, there may be other locks held at the same time (namely, PROC_LOCK) that uifind is not aware of. Here are a couple of suggested fixes: 1. Break uifind back into uifind, uicreate, and uiinsert. If uifind returns NULL, caller drops all locks, calls uicreate, grabs locks, checks uifind again, and calls uiinsert. 2. Split set*uid execution into lookup, (optionally) create, and modify phases. Locks only need to be held for lookup and modify. Is anyone else working on a fix? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message