Bring back previous fix for UVM vnode deadlock.

Bring back previous fix for UVM vnode deadlock.

tb@ reports that refaulting when there's contention on the vnode makes
firefox start very slowly on his machine.  To revisit when the fault
handler will be unlocked.

ok anton@

Original commit message:

Fix a deadlock between uvn_io() and uvn_flush(). While faulting on a
page backed by a vnode, uvn_io() will end up being called in order to
populate newly allocated pages using I/O on the backing vnode. Before
performing the I/O, newly allocated pages are flagged as busy by
uvn_get(), that is before uvn_io() tries to lock the vnode. Such pages
could then end up being flushed by uvn_flush() which already has
acquired the vnode lock. Since such pages are flagged as busy,
uvn_flush() will wait for them to be flagged as not busy. This will
never happens as uvn_io() cannot make progress until the vnode lock is
released.

Instead, grab the vnode lock before allocating and flagging pages as
busy in uvn_get(). This does extend the scope in uvn_get() in which the
vnode is locked but resolves the deadlock.

ok mpi@

Reported-by: syzbot+e63407b35dff08dbee02@syzkaller.appspotmail.com