Date: Thu, 19 Dec 2013 09:03:50 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs <freebsd-fs@FreeBSD.org> Subject: Re: namecache: numneg > 0 but ncneg is empty Message-ID: <20131219070350.GM59496@kib.kiev.ua> In-Reply-To: <52B16847.8090905@FreeBSD.org> References: <52B16847.8090905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--XAj4pGex3+LgE3R4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 18, 2013 at 11:17:59AM +0200, Andriy Gapon wrote:
>=20
> I've been running a test that exercises vfs, fs and namecache code quite =
a lot
> and I have run into the following panic:
>=20
> #2 0xffffffff808e9b43 in panic (fmt=3D<value optimized out>) at
> /usr/src/sys/kern/kern_shutdown.c:637
> #3 0xffffffff80ce57dd in trap_fatal (frame=3D0xc, eva=3D1844674407157877=
0679) at
> /usr/src/sys/amd64/amd64/trap.c:879
> #4 0xffffffff80ce58a6 in trap_pfault (frame=3D0xffffff9de1875260, usermo=
de=3D0) at
> /usr/src/sys/amd64/amd64/trap.c:700
> #5 0xffffffff80ce60d7 in trap (frame=3D0xffffff9de1875260) at
> /usr/src/sys/amd64/amd64/trap.c:463
> #6 0xffffffff80cce853 in calltrap () at /usr/src/sys/amd64/amd64/excepti=
on.S:232
> #7 0xffffffff8097b46d in cache_zap (ncp=3D0x0) at /usr/src/sys/kern/vfs_=
cache.c:417
> #8 0xffffffff8097c22f in cache_enter_time (dvp=3D0xfffffe031c7215f8,
> vp=3D0xfffffe0a684f05f8, cnp=3D0xffffff9de1875858, tsp=3D0x0, dtsp=3D0x0)=
at
> /usr/src/sys/kern/vfs_cache.c:902
> #9 0xffffffff81b9b26c in zfs_lookup (dvp=3D0xfffffe031c7215f8,
> nm=3D0xffffff9de1875460 "5", vpp=3D0xffffff9de1875830, cnp=3D0xffffff9de1=
875858,
> nameiop=3D1, cr=3D0xfffffe0a8f937800, td=3D0xfffffe04a80c2490, flags=3D0)
> at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs=
/zfs_vnops.c:1555
> #10 0xffffffff81b9b338 in zfs_freebsd_lookup (ap=3D0xffffff9de18755d0) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs=
/zfs_vnops.c:5946
> #11 0xffffffff80d8f403 in VOP_CACHEDLOOKUP_APV (vop=3D0xffffffff81c26ee0,
> a=3D0xffffff9de18755d0) at vnode_if.c:193
> #12 0xffffffff8097cef3 in vfs_cache_lookup (ap=3D<value optimized out>) at
> vnode_if.h:80
> #13 0xffffffff80d8f623 in VOP_LOOKUP_APV (vop=3D0xffffffff81c26ee0,
> a=3D0xffffff9de18756b0) at vnode_if.c:126
> #14 0xffffffff80984bed in lookup (ndp=3D0xffffff9de18757f0) at vnode_if.h=
:54
> #15 0xffffffff80985a43 in namei (ndp=3D0xffffff9de18757f0) at
> /usr/src/sys/kern/vfs_lookup.c:294
> #16 0xffffffff809981a2 in kern_mkdirat (td=3D0xfffffe04a80c2490, fd=3D-10=
0,
> path=3D0x801c19110 <Address 0x801c19110 out of bounds>, segflg=3DUIO_USER=
SPACE,
> mode=3D511) at /usr/src/sys/kern/vfs_syscalls.c:3830
> #17 0xffffffff809983f6 in kern_mkdir (td=3D<value optimized out>, path=3D=
<value
> optimized out>, segflg=3D<value optimized out>, mode=3D<value optimized o=
ut>) at
> /usr/src/sys/kern/vfs_syscalls.c:3810
> #18 0xffffffff80998414 in sys_mkdir (td=3D<value optimized out>, uap=3D<v=
alue
> optimized out>) at /usr/src/sys/kern/vfs_syscalls.c:3789
>=20
> (kgdb) fr 8
> #8 0xffffffff8097c22f in cache_enter_time (dvp=3D0xfffffe031c7215f8,
> vp=3D0xfffffe0a684f05f8, cnp=3D0xffffff9de1875858, tsp=3D0x0, dtsp=3D0x0)=
at
> /usr/src/sys/kern/vfs_cache.c:902
> 902 cache_zap(ncp);
> (kgdb) list
> 897 zap =3D 1;
> 898 }
> 899 if (hold)
> 900 vhold(dvp);
> 901 if (zap)
> 902 cache_zap(ncp);
> 903 CACHE_WUNLOCK();
> 904 }
> 905
> 906 /*
> (kgdb) i loc
> ncp =3D (struct namecache *) 0x0
> n2 =3D (struct namecache *) 0xffffffff8178a740
> ncpp =3D (struct nchashhead *) 0xffffff8ccde4e9b0
> hash =3D <value optimized out>
> flag =3D 0
> hold =3D 1
> zap =3D 1
> len =3D <value optimized out>
>=20
> (kgdb) p numneg
> $4 =3D 437
> (kgdb) p ncp
> $7 =3D (struct namecache *) 0x0
> (kgdb) p ncneg
> $8 =3D {tqh_first =3D 0x0, tqh_last =3D 0xffffffff8178a710}
>=20
>=20
> I am not sure that there is a bug in namecache, but if there is one, then=
the
> only suspicious place I could find is ".." handling in cache_enter_time().
>=20
Do you mean that numneg accounting is wrong for the case when the
existing ncp retargeted for dd ? This is the only issue I see there, but
it looks as the real case for the failure.
Testcase would be lot of lookups down the long directory hierarchy, and
than walking back through the ".." entries. Even if the thing does not
panic, the resulting length of the ncneg tailq should be strictly less
than the numneg.
diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c
index d46ba3d..33f5cce 100644
--- a/sys/kern/vfs_cache.c
+++ b/sys/kern/vfs_cache.c
@@ -748,16 +748,20 @@ cache_enter_time(dvp, vp, cnp, tsp, dtsp)
ncp->nc_flag & NCF_ISDOTDOT) {
KASSERT(ncp->nc_dvp =3D=3D dvp,
("wrong isdotdot parent"));
- if (ncp->nc_vp !=3D NULL)
+ if (ncp->nc_vp !=3D NULL) {
TAILQ_REMOVE(&ncp->nc_vp->v_cache_dst,
ncp, nc_dst);
- else
+ } else {
TAILQ_REMOVE(&ncneg, ncp, nc_dst);
- if (vp !=3D NULL)
+ numneg--;
+ }
+ if (vp !=3D NULL) {
TAILQ_INSERT_HEAD(&vp->v_cache_dst,
ncp, nc_dst);
- else
+ } else {
TAILQ_INSERT_TAIL(&ncneg, ncp, nc_dst);
+ numneg++;
+ }
ncp->nc_vp =3D vp;
CACHE_WUNLOCK();
return;
@@ -893,6 +897,8 @@ cache_enter_time(dvp, vp, cnp, tsp, dtsp)
}
if (numneg * ncnegfactor > numcache) {
ncp =3D TAILQ_FIRST(&ncneg);
+ KASSERT(ncp->nc_vp =3D=3D NULL, ("ncp %p vp %p on ncneg",
+ ncp, ncp->nc_vp));
zap =3D 1;
}
if (hold)
--XAj4pGex3+LgE3R4
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJSsppVAAoJEJDCuSvBvK1Bqk0P/R11cIkQ/5QwZNusRSpwXd7l
Q511uJTqSLcu7OlbCRLD1vO5WhCGNbPA6QcjpXd0Ey2JnKoT4ZJfOewxnKpzuqMn
Q+39X+WrJJLy7134muhXO+RiOZjf6p3fJeMdtSeMviLGwJUHpe/TKbz6DVq7zoJe
w/0Hse2himY62sDu8dMECyzReLaG2g3E9ah4fI9cXZJafmQU2FaxiLpGbJzBwEoq
ns65pySBmxZ9PQ6u02xfLZer6Ry0DYKbJ2Z65BgMdFiEKkgOiUYHezvYXXQKwRGC
pZ3u913h/IPXsjHrIp6mPh0mLU5rq+PgYoHAj+WpHPaAXagUVV0j8xVq5K1C6jgY
ygMt56wiNkVDnprvRsfS11LfJ0Jt2UOl0qeSCZAHGUDu+uRvylJkjtS66jgzvN8a
9l92rPnTFJ+Hp+Vl1vkPAG+Tkf5miuQ7Hwws6tlDJdgGVBBK/SLhBKwBrD0CudNi
aXAiDCZ34Jg0fVpVoQaD594UrsMSfN6oMF1SY+gsb4LGgEkKp8pGmZpVZqCJz7Vx
xI6YjkT1q39wf59WCfZ7/AeoTLBp/+NWTCLmB2JHApTi0o/6j91SeGNYQM4E3HdY
jZzwqcLAsmXkiyCc92YtKDDv8fQOYyV0vPoc9nQLm9b43aK3EdK4nrEYxJw6P0EY
N5Nhgi021G3v3Qn+YhZB
=Yf3U
-----END PGP SIGNATURE-----
--XAj4pGex3+LgE3R4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131219070350.GM59496>