On 09-Feb-02 Julian Elischer wrote: > John, (peter? others?) > > How is it that getting a ucred reference is guarded by PROC_LOCK(p) > but freeing it is guarded by mtx_lock(&Giant); > ? > > Call me naive, but shouldn't they be guarded by the same thing?
Naive, maybe. :-P The actual refcount for a ucred is protected by an internal mutex. The PROC_LOCK is to ensure that the value of p_ucred is up to date and doesn't change so that the cred doesn't get free'd out from under us. Giant is needed for crfree() since it can call free(). > Julian > > > On Fri, 8 Feb 2002, Julian Elischer wrote: > >> I'm a little worried about invariants because the behaviour when >> INVARIANTS is set wil be different to teh behaviour when it is off, which >> is 'strange' to say the least. Normally the behaviour si the same but you >> just check for invariant conditions. >> >> >> On Fri, 8 Feb 2002, John Baldwin wrote: >> >> > >> > On 08-Feb-02 Julian Elischer wrote: >> > > >> > > I'd like to commit the code to keep the ucred across userland, >> > > with the code to clear it to NULL kept under DEBUG ifdefs. >> > >> > Use INVARIANTS for the ifdef macro name, but sure. >> > >> > -- >> > >> > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ >> > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >> > >> >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-current" in the body of the message >> > -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message