From owner-freebsd-current Tue Jun 11 1:36:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id 6F83337B407 for ; Tue, 11 Jun 2002 01:36:51 -0700 (PDT) Received: (qmail 25296 invoked from network); 11 Jun 2002 08:36:50 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2002 08:36:50 -0000 Received: from laptop.baldwin.cx ([206.187.69.211]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g5B8amQ81393; Tue, 11 Jun 2002 04:36:48 -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: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> Date: Tue, 11 Jun 2002 04:36:41 -0400 (EDT) From: John Baldwin To: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 Cc: hiten@uk.FreeBSD.org, jrh@lab.it.uc3m.es, freebsd-current@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 10-Jun-2002 Mike Makonnen wrote: >> 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. >> > > Well... this is basically what happens > > setuid - creates a new ucred > - locks p > - calls change_ruid() > > change_ruid - calls uifind() > > uifind - does MALLOC w/ M_WAITOK > > After thinking about it for a while, this is the solution I came up > with: > > Each new struct ucred will carry an array of pointers to struct uidinfo. > This will be an array of 3 elements (a spare for cr_ruidinfo, > cr_uidinfo, null). Obviously, it gets added after ->cr_endcopy. > > When crget() is called it calls a function whose job it is to create an > array of pointers to struct uidinfo and allocate the memory for them. > > When uifind() is called it will be given an array of pointers to uidinfo > structs (the ones from ucred), in addition to the uid it is to lookup. > If it already has a uidinfo for that uid, then it returns that to the > calling function. If it can't find the uid, then it unhooks (copies the > address, and deletes it from the array) the last struct uidinfo from > the array, initializes it, inserts it into the hashtable and returns it > to the caller. > > When crfree is called it calls a function that deallocates the spare > structs uidinfo. > > This solution has the advantage that the only code that has to change is > the ucred and setuid/gid helper functions that already know about the > struct uidinfo functions. In fact only three functions not related to > uidinfo(9) need to be touched: proc0_init(), change_ruid(), > change_uid(). The disadvantage is the memory bloat and a small amount of > code complexity (but as I said, this is localized, and not very complex > either). > > Do you like it? > Should I go ahead and implement a patch? > Anything I overlooked? It won't work if you have to change a uidinfo more than once. I still prefer just doing the uifind() at the beginning of the function, passing in the uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's in case of failure. -- 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