ZFS: Deadlock during vnode recycling

Andriy Gapon avg at FreeBSD.org
Sun Oct 7 15:32:13 UTC 2012


In fact here is a real patch that I would like to propose:
http://people.freebsd.org/~avg/zfs-getnewvnode_reserve.diff

The patch incorporates the kib's patch for extending VFS API that helps to avoid
entering the vnode inactive/reclaim path from getnewvnode.

The patch should fix the problem reported in this thread and the problem from
"panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx ..."
thread that runs in parallel.

Reviews and testing are welcome.

Here is a draft of a commit message that also provides some additional details:

zfs: overhaul zfs_freebsd_reclaim and zfs_zget...

now that we do not need to fear recursion from getnewvnode into
zfs_inactive and zfs_freebsd_reclaim.
This removes the need for the delayed destruction of znodes via taskqueue,
thus making znode/vnode state machine a bit simpler.
Also, try to make zfs_zget saner with respected to doomed vnodes to avoid
a deadlock when zfs_zget is called from zfs_freebsd_recycle.

To do: pass locking flags parameter to zfs_zget, so that the zfs-vfs glue
code doesn't have to re-lock a vnode but could ask for proper locking
from the very start.


The patch also drops some redundant interlock acquisitions, since both
vop_inactive and vop_reclaim are called with exclusive vnode lock held.
-- 
Andriy Gapon


More information about the freebsd-fs mailing list