[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.