On 09/08/2016 02:48, Navdeep Parhar wrote: > Hello Andriy, > > I'm at r303837 and have had two panics today in zfs_rename. I have a > core for a kernel built with -O0. Let me know if you think it's related > to this commit and need more information. This is the stack: > > (also available at https://people.freebsd.org/~np/rename_panic.txt in > case the wide lines are hard to read in email).
Thank you very much for the report. More details are required for analysis. In frame 11 I would like to see objects pointed to by all arguments and additionally local variables tdzp, sdzp, zfsvfs and zilog. > (kgdb) bt > #0 doadump (textdump=0) at /root/ws/head/sys/kern/kern_shutdown.c:298 > #1 0xffffffff803f8692 in db_dump (dummy=-2100833195, dummy2=false, > dummy3=-1, dummy4=0xfffffe08604c6810 "") at > /root/ws/head/sys/ddb/db_command.c:533 > #2 0xffffffff803f847e in db_command (last_cmdp=0xffffffff821d40d8 > <db_last_command>, cmd_table=0x0, dopager=1) at > /root/ws/head/sys/ddb/db_command.c:440 > #3 0xffffffff803f801e in db_command_loop () at > /root/ws/head/sys/ddb/db_command.c:493 > #4 0xffffffff803fcf13 in db_trap (type=12, code=0) at > /root/ws/head/sys/ddb/db_main.c:251 > #5 0xffffffff8100116f in kdb_trap (type=12, code=0, > tf=0xfffffe08604c6fe0) at /root/ws/head/sys/kern/subr_kdb.c:654 > #6 0xffffffff8163df24 in trap_fatal (frame=0xfffffe08604c6fe0, > eva=18446744069414584336) at /root/ws/head/sys/amd64/amd64/trap.c:836 > #7 0xffffffff8163e53b in trap_pfault (frame=0xfffffe08604c6fe0, > usermode=0) at /root/ws/head/sys/amd64/amd64/trap.c:763 > #8 0xffffffff8163d1e2 in trap (frame=0xfffffe08604c6fe0) at > /root/ws/head/sys/amd64/amd64/trap.c:442 > #9 0xffffffff8163e63a in trap_check (frame=0xfffffe08604c6fe0) at > /root/ws/head/sys/amd64/amd64/trap.c:635 > #10 <signal handler called> > #11 0xffffffff82c7d455 in zfs_rename (sdvp=0xfffff80016e331d8, > svpp=0xfffffe08604c7318, scnp=0xfffffe08604c7750, > tdvp=0xfffff80156440000, tvpp=0xfffffe08604c7308, > tcnp=0xfffffe08604c7688, cr=0xfffff8001612e600) > at > /root/ws/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:3959 > #12 0xffffffff82c6f6a9 in zfs_freebsd_rename (ap=0xfffffe08604c73c8) at > /root/ws/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5275 > #13 0xffffffff8187d484 in VOP_RENAME_APV (vop=0xffffffff82d19bb0 > <zfs_vnodeops>, a=0xfffffe08604c73c8) at vnode_if.c:1547 > #14 0xffffffff810e5d41 in VOP_RENAME (fdvp=0xfffff80016e331d8, > fvp=0xfffff80174c02588, fcnp=0xfffffe08604c7750, > tdvp=0xfffff80156440000, tvp=0xfffff8017d7d1ce8, > tcnp=0xfffffe08604c7688) at ./vnode_if.h:636 > #15 0xffffffff810e5b17 in kern_renameat (td=0xfffff8010b855a40, > oldfd=-100, old=0x800a121a0 <error: Cannot access memory at address > 0x800a121a0>, newfd=-100, new=0x7fffffffcfee <error: Cannot access > memory at address 0x7fffffffcfee>, > pathseg=UIO_USERSPACE) at /root/ws/head/sys/kern/vfs_syscalls.c:3553 > #16 0xffffffff810e53d7 in sys_rename (td=0xfffff8010b855a40, > uap=0xfffffe08604c7a58) at /root/ws/head/sys/kern/vfs_syscalls.c:3427 > #17 0xffffffff83ce244d in filemon_wrapper_rename (td=0xfffff8010b855a40, > uap=0xfffffe08604c7a58) at > /root/ws/head/sys/modules/filemon/../../dev/filemon/filemon_wrapper.c:240 > #18 0xffffffff8163f1a9 in syscallenter (td=0xfffff8010b855a40, > sa=0xfffffe08604c7a48) at > /root/ws/head/sys/amd64/amd64/../../kern/subr_syscall.c:135 > #19 0xffffffff8163e9ea in amd64_syscall (td=0xfffff8010b855a40, > traced=0) at /root/ws/head/sys/amd64/amd64/trap.c:942 > > Regards, > Navdeep > > > On 08/04/2016 23:23, Andriy Gapon wrote: >> Author: avg >> Date: Fri Aug 5 06:23:06 2016 >> New Revision: 303763 >> URL: https://svnweb.freebsd.org/changeset/base/303763 >> >> Log: >> zfs: honour and make use of vfs vnode locking protocol >> >> ZFS POSIX Layer is originally written for Solaris VFS which is very >> different from FreeBSD VFS. Most importantly many things that FreeBSD VFS >> manages on behalf of all filesystems are implemented in ZPL in a different >> way. >> Thus, ZPL contains code that is redundant on FreeBSD or duplicates VFS >> functionality or, in the worst cases, badly interacts / interferes >> with VFS. >> >> The most prominent problem is a deadlock caused by the lock order reversal >> of vnode locks that may happen with concurrent zfs_rename() and lookup(). >> The deadlock is a result of zfs_rename() not observing the vnode locking >> contract expected by VFS. >> >> This commit removes all ZPL internal locking that protects parent-child >> relationships of filesystem nodes. These relationships are protected >> by vnode locks and the code is changed to take advantage of that fact >> and to properly interact with VFS. >> >> Removal of the internal locking allowed all ZPL dmu_tx_assign calls to >> use TXG_WAIT mode. >> >> Another victim, disputable perhaps, is ZFS support for filesystems with >> mixed case sensitivity. That support is not provided by the OS anyway, >> so in ZFS it was a buch of dead code. >> >> To do: >> - replace ZFS_ENTER mechanism with VFS managed / visible mechanism >> - replace zfs_zget with zfs_vget[f] as much as possible >> - get rid of not really useful now zfs_freebsd_* adapters >> - more cleanups of unneeded / unused code >> - fix / replace .zfs support >> >> PR: 209158 >> Reported by: many >> Tested by: many (thank you all!) >> MFC after: 5 days >> Sponsored by: HybridCluster / ClusterHQ >> Differential Revision: https://reviews.freebsd.org/D6533 >> >> Modified: >> head/sys/cddl/compat/opensolaris/sys/vnode.h >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_dir.h >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c >> > -- Andriy Gapon _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
