devfs: unlock the directory vnode around the call to dev_clone handler

[kib]

Summary

The lock around dev_clone is unfortunate because cloner might need to
take its own locks that establish the order with devfs vnodes, and then
transiently participates in further VFS locks order.  For instance, this
way the proctree_lock or allproc_lock become involved.

Unlock dvp, we can unwind if the vnode become doomed while cloner was
called.

Reported by:    pho

[markj]

sys/fs/devfs/devfs_vnops.c

1156

Why is it correct to handle the DOOMED case after checking cdev == NULL? It's not immediately clear to me.

[kib]

sys/fs/devfs/devfs_vnops.c

1156

Why is it not? If cdev == NULL, we fall to some of the paths that end up with return (ENOENT);. Either the devfs instance is being unmounted, and then DEVFS_DMP_DROP() is true and we use the exit path starting at line 1153 (patched). Or we break out of the loop, and since de == NULL, we return ENOENT in line 1179.

[markj]

sys/fs/devfs/devfs_vnops.c

1156

I see now, thanks. Specifically, I missed that we must fall into the de == NULL case if the case on line 1162 is hit.

[kib]

Add comment explaining why dvp is unlocked, and how possible reclamation is handled.