From owner-freebsd-current Sat Jun 8 7:57:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by hub.freebsd.org (Postfix) with ESMTP id 2960937B401 for ; Sat, 8 Jun 2002 07:57:37 -0700 (PDT) Received: (qmail 6100 invoked from network); 8 Jun 2002 14:57:36 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Jun 2002 14:57:36 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g58EvYF71838; Sat, 8 Jun 2002 10:57:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200206081214.g58CEYmq006939@kokeb.ambesa.net> Date: Sat, 08 Jun 2002 10:57:32 -0400 (EDT) From: John Baldwin To: Mike Makonnen Subject: RE: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 Cc: freebsd-current@FreeBSD.ORG, jrh@lab.it.uc3m.es, hiten@uk.FreeBSD.org 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 08-Jun-2002 Mike Makonnen wrote: > On Sat, 08 Jun 2002 04:03:40 -0700 (PDT) > Hiten Pandya wrote: > >> --- Juan Francisco Rodriguez Hervella wrote: >> > ../vm/uma_core.c:1160 >> > ../../../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> >> > Hope this help. Do you think these errors are alarming ? >> > I mean, do you recommend me to recopile my kernel again ? >> > (please noooooo, it takes me a lot of time to recompile whatever > thing :)> > > I also get these and I figured they're as good an excuse as any to jump > into the kernel code :-} This particular one (and others related to the > setuid/gid family of functions) occur because some time after PROC_LOCK > is called in set{uid,euid} and further down the call stack uidfind() > allocates some memory specifying the M_WAITOK flag. > > Is the solution to this to use M_NOWAIT and continue re-trying untill it > succeeds? Is there on-going smp work in locking down struct proc that > will eliminate this problem? Well, the real solution probably involves changing where we dink with uidinfo structs so we bump the reference count on teh new one before we grab the proc lock, change over to the new one while holding the proc lock, then release the reference to the old one after we are done. > Cheers, > Mike Makonnen > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message