Date: Tue, 18 Jun 2002 12:42:37 -0700 (PDT) From: Nate Lawson <nate@root.org> To: current@freebsd.org Subject: Suggested fixes for uidinfo "would sleep" messages Message-ID: <Pine.BSF.4.21.0206181226040.10665-100000@root.org>
next in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0206181226040.10665-100000>