On Sat, 08 Jun 2002 10:57:32 -0400 (EDT)
John Baldwin <[EMAIL PROTECTED]> 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
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
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
Do you like it?
Should I go ahead and implement a patch?
Anything I overlooked?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message