From owner-freebsd-current Tue Jun 11 2:55:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 2012C37B401; Tue, 11 Jun 2002 02:55:43 -0700 (PDT) Received: from kokeb.ambesa.net ([64.173.11.74]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXJ00AO3CWVXR@mta6.snfc21.pbi.net>; Tue, 11 Jun 2002 02:55:43 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5BA14OZ002287; Tue, 11 Jun 2002 03:01:04 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5BA13L3002278; Tue, 11 Jun 2002 03:01:03 -0700 (PDT envelope-from mikem) Date: Tue, 11 Jun 2002 03:01:02 -0700 From: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 In-reply-to: To: John Baldwin Cc: hiten@uk.FreeBSD.org, jrh@lab.it.uc3m.es, freebsd-current@FreeBSD.ORG Message-id: <200206111001.g5BA13L3002278@kokeb.ambesa.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> 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, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin wrote: > > 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. Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. With that assumption in mind I wanted to compartmentalize the allocation of struct uidinfo. It seemed cleaner to me to have only uifind() and its immediate callers have intimate knowledge struct uidinfo creation and destruction, but I suppose if setuid() (for example) knows enough to compare cr_ruid et al, its knowledge of one more member isn't that bad. Basically, I wanted to avoid having to touch every function that changes the r/e uid, and touch just those that already dealt with the uidinfo. In any case, I'll submit a patch to you doing it the way you suggested. Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message