kernel/vfs: Do not wait for removed vnodes to become unbusy.

Most of the time, that is harmless and will just cause a slight delay
before the vnode is removed and we return NULL instead of finding it.
However, in rare circumstances involving renames, we can wind up in
a deadlock with the thread that is trying to remove the vnode, and
would have to wait all the way to the timeout (a full ten seconds!).

The only vnodes not about to disappear from the table that can be both
"removed" and "busy" seem to be special vnodes like pipes, which will
be in an "unpublished" state while they are initially "busy" which we
can check for, in case something wants to wait for them.

The "dirconc" test readily triggered a pathological case of this behavior.
Before this commit, it ran for over 15 minutes before I killed it (and
it was not close to done at that point, either.) After this change,
it completes successfully in around 3 minutes or so on my test VM.

Thanks to [email protected] for pointing out this testcase and its
misbehavior on Haiku!

Change-Id: Id1accf0aaf0724e1aec927a437d3a2ac1596cd98

src/system/kernel/fs/vfs.cpp

@@ -1189,6 +1189,10 @@ restart:
 	AutoLocker<Vnode> nodeLocker(vnode);
 
 	if (vnode && vnode->IsBusy()) {
+		// vnodes in the Removed state (except ones still Unpublished)
+		// which are also Busy will disappear soon, so we do not wait for them.
+		const bool doNotWait = vnode->IsRemoved() && !vnode->IsUnpublished();
+
 		nodeLocker.Unlock();
 		rw_lock_read_unlock(&sVnodeLock);
 		if (!canWait) {
@@ -1196,7 +1200,7 @@ restart:
 				mountID, vnodeID);
 			return B_BUSY;
 		}
-		if (!retry_busy_vnode(tries, mountID, vnodeID))
+		if (doNotWait || !retry_busy_vnode(tries, mountID, vnodeID))
 			return B_BUSY;
 
 		rw_lock_read_lock(&sVnodeLock);