[Bug 258208] [zfs] locks up when using rollback or destroy on both 13.0-RELEASE & sysutils/openzfs port

From: <bugzilla-noreply_at_freebsd.org>
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.