Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Jun 2002 23:34:21 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        Don Lewis <dl-freebsd@catspoiler.org>
Cc:        bright@mu.org, current@FreeBSD.ORG
Subject:   Re: Suggested fixes for uidinfo "would sleep" messages
Message-ID:  <Pine.BSF.4.21.0206192329420.11755-100000@root.org>
In-Reply-To: <200206190554.g5J5sGM1064829@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Jun 2002, Don Lewis wrote:
> On 18 Jun, Alfred Perlstein wrote:
> > * Nate Lawson <nate@root.org> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0206192329420.11755-100000>