From owner-freebsd-current Wed Jun 19 23: 4:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from rootlabs.com (root.org [67.118.192.226]) by hub.freebsd.org (Postfix) with SMTP id 2E58637B404 for ; Wed, 19 Jun 2002 23:04:30 -0700 (PDT) Received: (qmail 11841 invoked by uid 1000); 20 Jun 2002 06:34:21 -0000 Date: Wed, 19 Jun 2002 23:34:21 -0700 (PDT) From: Nate Lawson To: Don Lewis Cc: bright@mu.org, current@FreeBSD.ORG Subject: Re: Suggested fixes for uidinfo "would sleep" messages In-Reply-To: <200206190554.g5J5sGM1064829@gw.catspoiler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002, Don Lewis wrote: > On 18 Jun, Alfred Perlstein wrote: > > * Nate Lawson [020618 12:17] wrote: > >> 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). > > ... > >> Is anyone else working on a fix? > > > > The code should not be holding proc locks over ui*() calls. > > I finally got tired of seeing these messages. Since I haven't seen > anybody post a patch, I bit the bullet and cranked one out. It could > use some examination to make sure that the reference counts are handled > properly and there aren't any leaks. I'm not terribly happy about > having to unhide the uidinfo stuff and expose it to the users of > change_{r,e}uid(), and I don't like allocating memory before checking > permissions, but it looks like the alternatives are worse. I like your patch although it does create one more avenue for programming errors. This is a very real problem as my -current box hangs hard after about 10 hours of uptime. It has no problems running -stable. Disabling cron has kept it from crashing for at least a few days. Does anyone have any other solutions? If not, what's the status on committing this, at least as a workaround for now? -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message