commit d04ac15542dd027f317a99d3c285028a2d28deae
author Sean Klein <smklein@google.com> Sat Mar 17 15:09:55 2018 -0700
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Mon Mar 19 23:10:49 2018 +0000
tree 5f7cefffbf4319807fcd2f790d80c192f840856b
parent 02af9c0faf9907a8d9eb7fa4530f5fb513e77944

[blobfs][minfs] Prevent lookup function from double-acquiring lock

An race condition (most reproducible in blobfs, with the null blob test,
on QEMU + ARM64 without KVM, but possible with any blob) can occur with
the following steps:

1) A Vnode is created, and has data which is being written
back to storage asynchronously.
2) All client-side connections to the Vnode are closed, resulting
in a final reference to the RefPtr from the async writeback
thread.
3) A client-side call to lookup the Vnode is issued. This lookup
call successfully acquires a reference to the Vnode, while holding
a lock on the "Vnode lookup table".
4) The writeback thread releases the reference to the vnode.
5) The lookup call (still holding the lock!) also releases a reference
to the Vnode -- this time, it's the last reference, so the Vnode's
fbl_recycle function is called. This function attempts to lock and
remove the Vnode from "Vnode lookup table", but it is UNSAFE to do
so: the lock is already held from earlier in the lookup call.

This double-lock causes blobfs to hang.

Fix: Avoid releasing references to Vnodes while holding the
|hash_lock_|.

Although this bug can only trigger with blobfs' implementation of
lookup & async writeback (since the minfs lookup implementation
may only release the last reference of unlinked vnodes, which
don't cause a lock to be acquired in the destructor), this
patch also refactors the minfs lookup function to be more resistant
to this class of failure conditions.

ZX-1842 #done

Change-Id: I3b680ed1cc059bdc5c9b47ca1b573d981af7e10a