From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:41:50 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2715015E for ; Tue, 18 Feb 2014 13:41:50 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 762A7164E for ; Tue, 18 Feb 2014 13:41:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA28116; Tue, 18 Feb 2014 15:41:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFkvi-000GAd-T3; Tue, 18 Feb 2014 15:41:46 +0200 Message-ID: <530362F7.5060403@FreeBSD.org> Date: Tue, 18 Feb 2014 15:41:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140215200259.GZ24664@kib.kiev.ua> In-Reply-To: <20140215200259.GZ24664@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 18 Feb 2014 13:41:50 -0000 on 15/02/2014 22:02 Konstantin Belousov said the following: > On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote: >> on 14/02/2014 21:18 Jeremie Le Hen said the following: >>> I've just got another occurence of the exact same panic. Any clue how >>> to debug this? >> >> Could you please obtain *vp from frame 12 ? >> >> The problem seems to be happening in this piece of ZFS code: if >> (cnp->cn_flags & ISDOTDOT) { ltype = VOP_ISLOCKED(dvp); VOP_UNLOCK(dvp, >> 0); } ZFS_EXIT(zfsvfs); error = vn_lock(*vpp, cnp->cn_lkflags); if >> (cnp->cn_flags & ISDOTDOT) vn_lock(dvp, ltype | LK_RETRY); >> >> ltype is apparently LK_SHARED and the assertion is apparently triggered >> by EDEADLK error. The error can occur only if a thread tries to obtain a >> lock in a shared mode when it already has the lock exclusively. My only >> explanation of how this could happen is that dvp == *vpp and cn_lkflags >> is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results >> in the same vnode. I think that this is only possible if dvp is the root >> vnode. I am not sure if my theory is correct though. Also, I am not sure >> if zfs_lookup() should be prepared to handle such a lookup or if this >> kind of lookup should be handled by upper/other layers. In this case >> these would be VFS lookup code and nullfs code. >> > > So, is VV_ROOT flag set on the corresponding ZFS vnode ? As Jeremy has just reported, yes, it is set. > Just in case, you could try the following change, but I doubt that it would > have any effect. Nullfs root vnode is cached so its VV_ROOT flag should > not be lost. Also, I never seen similar issue with UFS. I have never seen this issue with ZFS... before. > diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c index > fa6c4af..3f74579 100644 --- a/sys/fs/nullfs/null_subr.c +++ > b/sys/fs/nullfs/null_subr.c @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, > vpp) vp->v_type = lowervp->v_type; vp->v_data = xp; vp->v_vnlock = > lowervp->v_vnlock; + vp->v_vflag = lowervp->v_vflag & VV_ROOT; error = > insmntque1(vp, mp, null_insmntque_dtr, xp); if (error != 0) return > (error); > -- Andriy Gapon