ZPL locking changes in revision 303763 by avg, Fri Aug 5 06:23:06 2016 UTC caused assertion panics on attempt to change owner of a file having some extended attributes when built with DEBUG_VFS_LOCKS: KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe4f2443b060 assert_vop_elocked() at assert_vop_elocked+0x72/frame 0xfffffe4f2443b090 zfs_acl_chown_setattr() at zfs_acl_chown_setattr+0x1e/frame 0xfffffe4f2443b0c0 zfs_freebsd_setattr() at zfs_freebsd_setattr+0x149d/frame 0xfffffe4f2443b6f0 VOP_SETATTR_APV() at VOP_SETATTR_APV+0xab/frame 0xfffffe4f2443b720 setfown() at setfown+0xb9/frame 0xfffffe4f2443b830 kern_fchownat() at kern_fchownat+0x10b/frame 0xfffffe4f2443b970 sys_fchownat() at sys_fchownat+0x33/frame 0xfffffe4f2443b990 amd64_syscall() at amd64_syscall+0x4d8/frame 0xfffffe4f2443bab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe4f2443bab0 --- syscall (491, FreeBSD ELF64, sys_fchownat), rip = 0x80086cc3a, rsp = 0x7fffffffea58, rbp = 0x7fffffffeaa0 --- vnode 0xfffff801d55793b0: tag zfs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags (VI_ACTIVE) lock type zfs: UNLOCKED zfs_acl_chown_setattr: 0xfffff801d55793b0 is not exclusive locked but should be KDB: enter: lock violation
Created attachment 175084 [details] proposed patch for testing Alexander, could you please test the attached patch?
(In reply to Andriy Gapon from comment #1) This fixed the panic on my tests.
A commit references this bug: Author: avg Date: Sat Sep 24 08:13:16 UTC 2016 New revision: 306292 URL: https://svnweb.freebsd.org/changeset/base/306292 Log: fix vnode lock assertion for extended attributes directory Background. In ZFS a file with extended attributes has a special directory associated with it where each extended attribute is a file. The attribute's name is a file name and its value is a file content. When the ownership of a file with extended attributes is changed, ZFS also changes ownership of the special directory. This is where the bug was hit. The bug was introduced in r209158. Nota bene. ZFS vnode locks are typically acquired before z_teardown_lock (i.e., before ZFS_ENTER). But this is not the case for the vnodes that represent the extended attribute directory and files. Those are always locked after ZFS_ENTER. This is confusing and fragile. PR: 212702 Reported by: Christian Fuss to FreeNAS Tested by: mav MFC after: 1 week Changes: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
Link to the original FreeNAS report: https://bugs.freenas.org/issues/17517