[Bug 258208] [zfs] locks up when using rollback or destroy on both 13.0-RELEASE & sysutils/openzfs port
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 15 Oct 2021 09:37:12 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258208
--- Comment #12 from Andriy Gapon <avg@FreeBSD.org> ---
And the commit message:
Author: Andriy Gapon <avg@icyb.net.ua>
AuthorDate: Fri Nov 16 12:11:45 2012 +0200
zfs: introduce zfs_freebsd_lock and zfs_freebsd_unlock...
These vnode operations acquire and release z_teardown_lock in addition
to the normal operations on the vnode lock.
This is a half-step towards fixing lock order problems between VM page
busying "locks" and ZFS internal locks. In particular, now z_teardown_lock
is always acquired prior to page busying (the same as the vnode lock).
Ideally I wanted z_teardown_lock to be acquired before the vnode lock, but
this is not possible to implement using VOP_LOCK1 approach.
Additional effect of this change is that now all ZFS vnode ops are
guaranteed
to be protected with z_teardown_lock. Previously some FreeBSD-specific
operations accessed znodes and zfsvfs without calling ZFS_ENTER first.
Consequentially, after this change ZFS_ENTER calls in the vnode ops has
become redundant. They are still needed in ZFS vfs ops.
This change should fix a deadlock between
vn_pages_remove/vnode_pager_setsize
called from zfs_rezget with z_teardown_lock held and putpages operation
blocked on z_teardown_lock while entering zfs_write.
This change has also made z_teardown_inactive_lock redundant.
The only remaining LOR between the page busying and ZFS is with ZFS range
locks. This should be fixed by introducing VOP_RANGELOCK to FreeBSD VFS,
placing calls to this operation at strategic places and implementing the
op for ZFS using the ZFS rangelock.
--
You are receiving this mail because:
You are the assignee for the bug.