making crdup()/crcopy() safe??

[Gleb Smirnoff]

  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.

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?

Attached patch demonstrates what I am trying to address, but I'm not sure
that this temporary placing on td_ucred is really unsafe. Can you please
look at this?

-- 
Totus tuus, Glebius.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfs_cred.diff
Type: text/x-diff
Size: 1713 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20111220/f7d1d82e/nfs_cred.bin