Date: Tue, 11 Jun 2002 03:01:02 -0700 From: Mike Makonnen <makonnen@pacbell.net> To: John Baldwin <jhb@FreeBSD.ORG> Cc: hiten@uk.FreeBSD.org, jrh@lab.it.uc3m.es, freebsd-current@FreeBSD.ORG Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 Message-ID: <200206111001.g5BA13L3002278@kokeb.ambesa.net> In-Reply-To: <XFMail.20020611043641.jhb@FreeBSD.org> References: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> <XFMail.20020611043641.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin <jhb@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206111001.g5BA13L3002278>