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

Looks like the bugzilla is acting up today again…

Setting “sharenfs=off” on the new directories seems make the copying to better, Have now copied 3472 filesystems without a deadlock.

I agree that it feels like there is a double lock/deadlock somewhere in the extattr handling code. Here’s procstat entries from three different runs that all ended in a deadlock btw:

# egrep 'VOP|rms_wlock' /tmp/procstat-kka.out

22829 103712 mountd              -                   mi_switch+0xbc _sleep+0x19e rms_wlock+0xb0 zfs_mount+0x38c vfs_domount_update+0x3b6 vfs_domount+0x289 vfs_donmount+0x947 sys_nmount+0x60 amd64_syscall+0x126 fast_syscall_common+0xf8

63998 290883 bsdtar              -                   mi_switch+0xbc _sleep+0x19e rms_rlock_fallback+0x90 zfs_lookup+0x74 zfs_deleteextattr_dir+0x38 zfs_setextattr+0x7dc VOP_SETEXTATTR_APV+0x24 extattr_set_vp+0x11d kern_extattr_set_path+0x14e sys_extattr_set_link+0x6b amd64_syscall+0x126 fast_syscall_common+0xf8


# egrep 'VOP|rms_wlock' /tmp/procstat-kka-2.out

23239 104623 mountd              -                   mi_switch+0xbc _sleep+0x19e rms_wlock+0xb0 zfs_mount+0x38c vfs_domount_update+0x3b6 vfs_domount+0x289 vfs_donmount+0x947 sys_nmount+0x60 amd64_syscall+0x126 fast_syscall_common+0xf8

38035 105881 rsync               -                   mi_switch+0xbc _sleep+0x19e rms_rlock_fallback+0x90 zfs_freebsd_open+0x34 VOP_OPEN_APV+0x19 vn_open_vnode+0x1e0 vn_open_cred+0x6f2 zfs_setextattr+0x4ec VOP_SETEXTATTR_APV+0x24 extattr_set_vp+0x11d kern_extattr_set_path+0x14e sys_extattr_set_link+0x6b amd64_syscall+0x126 fast_syscall_common+0xf8


# egrep 'VOP|rms_wlock' /tmp/procstat-kka-3.out

20872 103630 mountd              -                   mi_switch+0xbc _sleep+0x19e rms_wlock+0xb0 zfs_mount+0x38c vfs_domount_update+0x3b6 vfs_domount+0x289 vfs_donmount+0x947 sys_nmount+0x60 amd64_syscall+0x126 fast_syscall_common+0xf8

40121 103746 rsync               -                   mi_switch+0xbc _sleep+0x19e rms_rlock_fallback+0x90 zfs_setattr+0x96 zfs_freebsd_setattr+0x411 VOP_SETATTR_APV+0x24 setfown+0xb1 kern_fchownat+0x159 sys_lchown+0x26 amd64_syscall+0x126 fast_syscall_common+0xf8

40122 104328 rsync               -                   mi_switch+0xbc _sleep+0x19e rms_rlock_fallback+0x90 zfs_lookup+0x74 zfs_deleteextattr_dir+0x38 zfs_setextattr+0x7dc VOP_SETEXTATTR_APV+0x24 extattr_set_vp+0x11d kern_extattr_set_path+0x14e sys_extattr_set_link+0x6b amd64_syscall+0x126 fast_syscall_common+0xf8


(I switched from using tar to rsync after the first run)

- Peter

> On 16 Feb 2026, at 08:13, [email protected] wrote:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293198
> 
> Konstantin Belousov <[email protected]> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |[email protected]
> 
> --- Comment #6 from Konstantin Belousov <[email protected]> ---
> (In reply to Peter Eriksson from comment #5)
> I _suspect_ that was is happen there is lock recursion.
> 
> Note that the thread 105881 entered VOP_SETEXTATTR(), which (there is my guess)
> taken the read lock, and after that it called VOP_OPEN(), which tries to take
> the
> read lock once more.
> 
> Meantime, the thread 104623 tries to take the same lock in the write mode, that
> 1. blocks further readers
> 2. blocks the thread itself because there is waiting writer
> 
> And the system deadlocks.  Either zfs should stop recursing into VFS on extattr
> ops,
> or the lock should be not taken recursively, or it should be changed to allow
> readers to recurse even in presence of writers contenders.  The later would
> mean
> that writers cannot make progress if there is steady number of readers.
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.