From owner-freebsd-current@FreeBSD.ORG Fri Mar 13 03:35:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2EA0106566C; Fri, 13 Mar 2009 03:35:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 97F668FC08; Fri, 13 Mar 2009 03:35:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz8 with SMTP id 8so2408659bwz.43 for ; Thu, 12 Mar 2009 20:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=p4L2Emsls1HZN7qXi4LnlpcmFtBzyXm70O0ooO3Umxg=; b=QAf1vs/dngfcu8PZzBIoSfOYt/LFrsmzPJLWttlRk+KmuT4n1Z/dgkndAfQgz1CnoP zO0o2U7eoLqkcHxkS/g217+n2yKs8eoJXoQhBTOU0GtPW36bwezS7WEwGM1Vruh+MXe5 b3XpuPK+Y2h6SqWw5nMw+rE7pmrZiqePXPlso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qQ4N5+bJc9ee2ackT/GeCTPg5+7FPUhm5O2I8CPXb4hMsl34vs+/Oet9Dxr/xBrLX3 Zawbm8oWrYL6BO9eDeqxk+mV/rfHKskk5VmF/gKXACGF78e/iDurQV3/QeBFU6hNzocZ tVkoMNSa7f+6i9QV+bMr4dkKHSW9uW0kLRdbQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.103.225.11 with SMTP id c11mr341197mur.24.1236915353353; Thu, 12 Mar 2009 20:35:53 -0700 (PDT) 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> Date: Fri, 13 Mar 2009 04:35:53 +0100 X-Google-Sender-Auth: e7556ceea6dc0340 Message-ID: <3bbf2fe10903122035i20b2767cod2322c39c6f850ee@mail.gmail.com> From: Attilio Rao To: Anonymous Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , freebsd-current@freebsd.org, Tim Kientzle , Mark Powell , Peter Schuller Subject: Re: repeatable ZFS panic: share->excl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 03:35:56 -0000 2009/3/12, Anonymous : > Tim Kientzle 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