Date: Sat, 15 Feb 2014 22:02:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <20140215200259.GZ24664@kib.kiev.ua> In-Reply-To: <52FF59B8.1080206@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--xp5T+jWXk9cMuWlh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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?
>=20
> Could you please obtain *vp from frame 12 ?
>=20
> The problem seems to be happening in this piece of ZFS code:
> if (cnp->cn_flags & ISDOTDOT) {
> ltype =3D VOP_ISLOCKED(dvp);
> VOP_UNLOCK(dvp, 0);
> }
> ZFS_EXIT(zfsvfs);
> error =3D vn_lock(*vpp, cnp->cn_lkflags);
> if (cnp->cn_flags & ISDOTDOT)
> vn_lock(dvp, ltype | LK_RETRY);
>=20
> 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 lo=
ck in a
> shared mode when it already has the lock exclusively.
> My only explanation of how this could happen is that dvp =3D=3D *vpp and =
cn_lkflags
> is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results i=
n 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 l=
ookup
> or if this kind of lookup should be handled by upper/other layers. In th=
is case
> these would be VFS lookup code and nullfs code.
>=20
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 =3D lowervp->v_type;
vp->v_data =3D xp;
vp->v_vnlock =3D lowervp->v_vnlock;
+ vp->v_vflag =3D lowervp->v_vflag & VV_ROOT;
error =3D insmntque1(vp, mp, null_insmntque_dtr, xp);
if (error !=3D 0)
return (error);
--xp5T+jWXk9cMuWlh
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJS/8fyAAoJEJDCuSvBvK1BlnwQAJPH1uXPUh/NlDP5h1WixbUB
mdUvNzBvbU+LYV/sCU+GSvN6x78Sr3V5rNUEKbGUQVOu81jIpvyy0GQlUDmMshTq
ix+123xvR80gz2/XnZ6NmeVdg4f0VxDPBVgt+sCz+X5RhOVxt0QgxKspFQT0jX/f
+DweE4NOLthySsRA49UEOruhlcdA0SSz/h/zZghewutu3FxwmEdm8GC/ZG52YAvw
yA6ki7FSQfgGG8JGDY/34Y6Gn9hehHqPDPKRLEDT/0DtQTtwcQAEtrNeuNXw2Gz/
MYMz0TOtNumwhUF3WhcVuFVRIppDrDyi4tpWFg8cg6z8R4BJe05WPIxHw+NQztNc
WKKPyQrHhrU5+ENK9nsRjpTqFpba+C+ALlXSZ29juBNcwkXqLTTMHfGhvPMrLRnX
pVzarQYl+6+1qYrtFvXWGrVV1UdgFN9+xHVBGF2F1evoXRSbILWGV3Cc1PFeiSJs
I79ku57OSesC1eZXmAQX0Q5B1YFS0hhFVXivaG0yUQmF3L+fYvRpbCB0Zt9mrME4
BAw7KKBElODp7JvsNrtUTeGGt7U6vE661VJ1ZavZNotlN55REPjVhKIh3yPEaAbG
jg/X8RyUd2bPkK1G9WsJZr4Y3i05oqN/3kv/sBNdH2AQ0xZCzL1wHi/MuHNZQkce
J+YSCfKaKAcRQyvJh0T4
=Kf/c
-----END PGP SIGNATURE-----
--xp5T+jWXk9cMuWlh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140215200259.GZ24664>