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
../../../vm/uma_core.c:1327: could sleep with "process lock" locked from

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).


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?


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

Reply via email to