From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:14:34 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53F164B0; Tue, 18 Feb 2014 13:14:34 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17FDF135B; Tue, 18 Feb 2014 13:14:33 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 9D4A01023F6; Tue, 18 Feb 2014 13:14:26 +0000 (UTC) Date: Tue, 18 Feb 2014 14:14:26 +0100 From: Jeremie Le Hen To: Konstantin Belousov Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <20140218131426.GE3783@caravan.chchile.org> Mail-Followup-To: Konstantin Belousov , Andriy Gapon , freebsd-current@FreeBSD.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140215200259.GZ24664@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@FreeBSD.org, Andriy Gapon 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:14:34 -0000 On Sat, Feb 15, 2014 at 10:02:59PM +0200, Konstantin Belousov wrote: > 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 ? > > 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. > > 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); I've applied it and recompiling my kernel right now. I cannot really reproduce the problem for sure: it sometimes happens when I'm performing file manipulations on command-line on my nullfs-mounted zfs dataset; right after the reboot, I try again and it works. Well, now I'm writing this, this could well be the problem you describe: right after the boot I guess the root vnode is cached and still here. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons.