Re: making crdup()/crcopy() safe??

On Tuesday, December 20, 2011 2:31:40 pm Gleb Smirnoff wrote:
>   John,
> 
> On Tue, Dec 20, 2011 at 09:00:39AM -0500, John Baldwin wrote:
> J> In general the caller of crdup is expected to hold a reference on cred or 
some 
> J> other lock to ensure that cred remains valid and cannot be free'd while 
it is 
> J> being duplicated.  There is no global lock that crdup can hold for that, 
> J> instead the caller is required to guarantee that.
> 
> I already noticed to Rick in a private email, that there is suspisious
> place in new NFS, where newly allocated (via crdup) cred is temporarily
> placed on td_ucred, and then removed at the end of function. The function
> may sleep in malloc() and also block on mutexes.

None of that matters.  Only curthread touches td_ucred.  It isn't going to 
free its own credential while it is asleep. :)

> I suspect, that it may happen, that some other kernel facility performs
> crfree(td->td_ucred), and later on we are using already freed cred.
> 
> However, I can't imagine which facility may do this. What if process gets
> SIGKILL while its thread is blocked on mutex or sleeping? Would it
> be reaped after it yields or before?

No, a signal is merely marked as pending.  It isn't delivered to a thread in 
the kernel until it exits back out of the kernel and prepares to return to 
userland (e.g. in userret()).  Only at that time will the thread actually be 
killed.

-- 
John Baldwin