Date: Fri, 13 Mar 2009 04:35:53 +0100 From: Attilio Rao <attilio@freebsd.org> To: Anonymous <swell.k@gmail.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-current@freebsd.org, Tim Kientzle <kientzle@freebsd.org>, Mark Powell <M.S.Powell@salford.ac.uk>, Peter Schuller <peter.schuller@infidyne.com> Subject: Re: repeatable ZFS panic: share->excl Message-ID: <3bbf2fe10903122035i20b2767cod2322c39c6f850ee@mail.gmail.com> In-Reply-To: <86r6124f2v.fsf@gmail.com> References: <20090312175345.Y80227@rust.salford.ac.uk> <20090312191333.GA97342@hyperion.scode.org> <49B97617.8010709@freebsd.org> <86r6124f2v.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/3/12, Anonymous <swell.k@gmail.com>: > Tim Kientzle <kientzle@freebsd.org> writes: > > > Peter Schuller wrote: > >>> First problem I notice is a panic, which seems to occur every > >>> time 'tar' is used. Might be unrelated to tar, but it definately > >>> provokes it. Simply the tar command or a pkg_add causes it. > >> > >> See the "ZFS/extattr lockup"/"bsdtar lockup on current" threads from > >> the past handful of days. > > > > I think this may be a different problem. > > The earlier thread involved a ZFS bug that causes > > it to lock up if it receives a request to enumerate > > extended attributes on a file (via extattr_list_link > > system call). Tar recently added support for > > backing up extended attributes. I've disabled > > that support until this particular ZFS problem can > > be fixed. > > > I guess you're wrong, it's same issue. Here is output from unmodified > kernel (r189728) under qemu which looks exactly as on that > screenshot. Perhaps, the panic is triggered by INVARIANTS. > > # lsextattr -h user foo > shared lock of (lockmgr) zfs @ /usr/src/sys/kern/vfs_lookup.c:477 > while exclusively locked from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152 > panic: share->excl > cpuid = 0 > KDB: enter: panic > [thread pid 105 tid 100078 ] > Stopped at kdb_enter+0x3d: movq $0,0x662538(%rip) > > db> bt > Tracing pid 105 tid 100078 td 0xffffff00015bea80 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > witness_checkorder() at witness_checkorder+0x16e > __lockmgr_args() at __lockmgr_args+0xd1b > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x57 > lookup() at lookup+0xf4 > namei() at namei+0x545 > zfs_listextattr() at zfs_listextattr+0x18c > VOP_LISTEXTATTR_APV() at VOP_LISTEXTATTR_APV+0xb5 > extattr_list_vp() at extattr_list_vp+0x22a > extattr_list_link() at extattr_list_link+0xc3 > syscall() at syscall+0x1e7 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (439, FreeBSD ELF64, extattr_list_link), rip = 0x800692e4c, rsp = 0x7fffffffed08, rbp = 0x7fffffffede0 --- > > db> show all locks > Process 105 (lsextattr) thread 0xffffff00015bea80 (100078) > exclusive lockmgr zfs (zfs) r = 0 (0xffffff0001581578) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152 > exclusive lockmgr zfs (zfs) r = 0 (0xffffff0001581a58) locked @ /usr/src/sys/kern/vfs_extattr.c:668 > > db> show lockedvnods > Locked vnodes > > 0xffffff00015819c0: tag zfs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > v_object 0xffffff0001574898 ref 0 pages 0 > lock type zfs: EXCL by thread 0xffffff00015bea80 (pid 105) > #0 0xffffffff80530568 at __lockmgr_args+0x758 > #1 0xffffffff805c0fd9 at vop_stdlock+0x39 > #2 0xffffffff808557db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805dd6a7 at _vn_lock+0x57 > #4 0xffffffff805c2f20 at extattr_list_vp+0xb0 > #5 0xffffffff805c3173 at extattr_list_link+0xc3 > #6 0xffffffff8080f227 at syscall+0x1e7 > #7 0xffffffff807ec39b at Xfast_syscall+0xab > > 0xffffff00015814e0: tag zfs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type zfs: EXCL by thread 0xffffff00015bea80 (pid 105) > #0 0xffffffff80530568 at __lockmgr_args+0x758 > #1 0xffffffff805c0fd9 at vop_stdlock+0x39 > #2 0xffffffff808557db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805dd6a7 at _vn_lock+0x57 > #4 0xffffffff8108405e at zfs_znode_cache_constructor+0x4e > #5 0xffffffff81085029 at zfs_znode_alloc+0x39 > #6 0xffffffff81085915 at zfs_mknode+0x205 > #7 0xffffffff810948f5 at zfs_make_xattrdir+0x155 > #8 0xffffffff81095bc3 at zfs_get_xattrdir+0xd3 > #9 0xffffffff810a4dbf at zfs_lookup+0x11f > #10 0xffffffff810a51d8 at zfs_listextattr+0x128 > #11 0xffffffff80853255 at VOP_LISTEXTATTR_APV+0xb5 > #12 0xffffffff805c309a at extattr_list_vp+0x22a > #13 0xffffffff805c3173 at extattr_list_link+0xc3 > #14 0xffffffff8080f227 at syscall+0x1e7 > #15 0xffffffff807ec39b at Xfast_syscall+0xab Could you please re-enable the extended attributes on bsdtar, try this patch and report to me?: http://www.freebsd.org/~attilio/zfs_vnops.diff (sorry if it is untested but I just don't have any ZFS machine). Actually, I think the problem is that zfs_lookup() doesn't get the correct handover once the extended attributes directory vnode is retrieved. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10903122035i20b2767cod2322c39c6f850ee>