[Bug 293198] zfs deadlock while copying many files, vfs_deleteextattr_dir-related?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293198

--- Comment #9 from Rick Macklem <[email protected]> ---
(In reply to Konstantin Belousov from comment #6)
Yep, my assessment is about the same.
zfs_enter_verify_zp()/zfs_exit() gets called multiple
times during zfs_setextattr(), which allows the mountd
thread doing nmount() to put the exports on the mount
point to acquire the write (exclusive) lock while
zfs_setextattr() is in progress.

I think the fix involves adding an extra "already locked"
argument to zfs_lookup(), zfs_open() { and maybe others }
to avoid re-locking via zfs_enter_verify_zp()/zfs_exit().

But, as Kostik notes, it is not going to be a small patch,
because all the VOP_xxx() calls need to be replaced by the
zfs_xxx() calls below them, so the extra argument can be
passed in correctly. (The VOP_xxx() calls don't know they
are being called from zfs_setextattr().)
--> If there was a way to do rm_rowned() { test for ownership
    of a read lock }, this could be patched much more easily.
    Kostik, I'm guessing that isn't something easily done?

--- Comment #10 from Rick Macklem <[email protected]> ---
(In reply to Konstantin Belousov from comment #6)
Yep, my assessment is about the same.
zfs_enter_verify_zp()/zfs_exit() gets called multiple
times during zfs_setextattr(), which allows the mountd
thread doing nmount() to put the exports on the mount
point to acquire the write (exclusive) lock while
zfs_setextattr() is in progress.

I think the fix involves adding an extra "already locked"
argument to zfs_lookup(), zfs_open() { and maybe others }
to avoid re-locking via zfs_enter_verify_zp()/zfs_exit().

But, as Kostik notes, it is not going to be a small patch,
because all the VOP_xxx() calls need to be replaced by the
zfs_xxx() calls below them, so the extra argument can be
passed in correctly. (The VOP_xxx() calls don't know they
are being called from zfs_setextattr().)
--> If there was a way to do rm_rowned() { test for ownership
    of a read lock }, this could be patched much more easily.
    Kostik, I'm guessing that isn't something easily done?

-- 
You are receiving this mail because:
You are the assignee for the bug.