From owner-freebsd-current Mon Jun 10 2:27:17 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 9D24E37B409; Mon, 10 Jun 2002 02:27:13 -0700 (PDT) Received: from kokeb.ambesa.net ([64.173.9.235]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXH008XSGXDSG@mta6.snfc21.pbi.net>; Mon, 10 Jun 2002 02:27:13 -0700 (PDT) Received: from kokeb.ambesa.net (dev1ant@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5A9WTVF008407; Mon, 10 Jun 2002 02:32:29 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5A9WPe1008406; Mon, 10 Jun 2002 02:32:25 -0700 (PDT envelope-from mikem) Date: Mon, 10 Jun 2002 02:32:24 -0700 From: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 In-reply-to: To: John Baldwin Cc: freebsd-current@FreeBSD.ORG, jrh@lab.it.uc3m.es, hiten@uk.FreeBSD.org Message-id: <200206100932.g5A9WPe1008406@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: <200206081214.g58CEYmq006939@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 Sat, 08 Jun 2002 10:57:32 -0400 (EDT) John Baldwin wrote: > > > > 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. > 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? Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message