Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Dec 2006 13:29:20 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Yoichi Nakayama <yoichi@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: kern/105229: panic in sync_fsync
Message-ID:  <20061204112920.GJ35681@deviant.kiev.zoral.com.ua>
In-Reply-To: <87mz66prrc.wl%yoichi@FreeBSD.org>
References:  <200611062349.kA6NnbCG051817@www.freebsd.org> <20061107192218.GB1624@kobe.laptop> <878ximm418.wl%yoichi@FreeBSD.org> <20061109112035.GA1722@kobe.laptop> <86mz709d7u.wl%yoichi@geiin.org> <87vela6xnm.wl%yoichi@FreeBSD.org> <20061120152640.GH1841@deviant.kiev.zoral.com.ua> <87u00u6qqh.wl%yoichi@FreeBSD.org> <87mz66prrc.wl%yoichi@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--iRjOs3ViPWHdlw/I
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 02, 2006 at 06:32:39PM +0900, Yoichi Nakayama wrote:
> At Tue, 21 Nov 2006 01:13:26 +0900,
> Yoichi Nakayama wrote:
> >=20
> > At Mon, 20 Nov 2006 17:26:40 +0200,
> > Kostik Belousov wrote:
> > > > panic: mtx_lock() of spin mutex vnode interlock @ /usr/src/sys/kern=
/vfs_subr.c:2855
> > > >   ...
> > > > #13 0xc06b131f in panic (fmt=3D0xc0930a10 "mtx_lock() of spin mutex=
 %s @ %s:%d")
> > > > ---Type <return> to continue, or q <return> to quit---
> > > >     at /usr/src/sys/kern/kern_shutdown.c:551
> > > > #14 0xc06a85c0 in _mtx_lock_flags (m=3D0xc58593a8, opts=3D0,=20
> > > >     file=3D0xc093c091 "/usr/src/sys/kern/vfs_subr.c", line=3D2855)
> > > >     at /usr/src/sys/kern/kern_mutex.c:131
> > > > #15 0xc0712570 in vfs_msync (mp=3D0xc3d4e538, flags=3D2)
> > > >     at /usr/src/sys/kern/vfs_subr.c:2855
> > > Please, show the output of the "p *vp" and "p *mp" at this frame.
> > >=20
> > > > #16 0xc0712d21 in sync_fsync (ap=3D0x0) at /usr/src/sys/kern/vfs_su=
br.c:3089
> > > > #17 0xc08bafde in VOP_FSYNC_APV (vop=3D0x0, a=3D0xe3c39cb4) at vnod=
e_if.c:1007
> > > > #18 0xc071094e in sync_vnode (bo=3D0xc3d4b704, td=3D0xc3924c40) at =
vnode_if.h:537
> > > > #19 0xc0710bcd in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1691
> > > > #20 0xc069b908 in fork_exit (callout=3D0xc07109dc <sched_sync>, arg=
=3D0x0,=20
> > > >     frame=3D0xe3c39d38) at /usr/src/sys/kern/kern_fork.c:834
> > > > #21 0xc08943bc in fork_trampoline () at /usr/src/sys/i386/i386/exce=
ption.s:199
>=20
> # kgdb kernel.debug /var/crash/vmcore.14
>    ...
> #11 0xc06b40f3 in panic (fmt=3D0xc0935c1c "mtx_lock() of spin mutex %s @ =
%s:%d")
>     at /usr/src/sys/kern/kern_shutdown.c:551
> ---Type <return> to continue, or q <return> to quit---
> #12 0xc06ab398 in _mtx_lock_flags (m=3D0xc6f043a8, opts=3D0,=20
>     file=3D0xc09412af "/usr/src/sys/kern/vfs_subr.c", line=3D2855)
>     at /usr/src/sys/kern/kern_mutex.c:131
> #13 0xc071532c in vfs_msync (mp=3D0xc441b538, flags=3D2)
>     at /usr/src/sys/kern/vfs_subr.c:2855
> #14 0xc0715add in sync_fsync (ap=3D0x0) at /usr/src/sys/kern/vfs_subr.c:3=
089
> #15 0xc08bfcbe in VOP_FSYNC_APV (vop=3D0x12, a=3D0xe4306cb4) at vnode_if.=
c:1007
> #16 0xc07136c8 in sync_vnode (bo=3D0xc43a4e58, td=3D0xc3ff2a80) at vnode_=
if.h:537
> #17 0xc0713945 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1691
> #18 0xc069e6e0 in fork_exit (callout=3D0xc0713754 <sched_sync>, arg=3D0x0=
,=20
>     frame=3D0xe4306d38) at /usr/src/sys/kern/kern_fork.c:834
> #19 0xc089868c in fork_trampoline () at /usr/src/sys/i386/i386/exception.=
s:199
> (kgdb) select 13
> (kgdb) p *vp
> $1 =3D {v_type =3D VREG, v_tag =3D 0xc093f146 "ufs", v_op =3D 0xc09f51c0,=
 v_data =3D 0xc733f948, v_mount =3D 0xc441b538,=20
>   v_nmntvnodes =3D {tqe_next =3D 0xc449fc00, tqe_prev =3D 0xc8028ca4}, v_=
un =3D {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0,=20
>     vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next =3D 0x0, le_prev =3D 0x=
c422b428}, v_hash =3D 949946, v_cache_src =3D {
>     lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, tqh_last =3D 0=
xc6f04354}, v_dd =3D 0x0, v_cstart =3D 0, v_lasta =3D 0,=20
>   v_lastw =3D 0, v_clen =3D 0, v_lock =3D {lk_object =3D {lo_name =3D 0xc=
093f146 "ufs", lo_type =3D 0x0, lo_flags =3D 64,=20
>       lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =
=3D 0x0}}, lk_interlock =3D 0xc0a384c8, lk_sharecount =3D 0,=20
>     lk_waitcount =3D 0, lk_exclusivecount =3D 0, lk_prio =3D 80, lk_timo =
=3D 51, lk_lockholder =3D 0xffffffff, lk_newlock =3D 0x0},=20
>   v_interlock =3D {mtx_object =3D {lo_name =3D 0xc093b247 "vnode interloc=
k", lo_type =3D 0xc093b247 "vnode interlock",=20
>       lo_flags =3D 196608, lo_witness_data =3D {lod_list =3D {stqe_next =
=3D 0xc0a49150}, lod_witness =3D 0xc0a49150}}, mtx_lock =3D 4,=20
>     mtx_recurse =3D 0}, v_vnlock =3D 0xc6f0437c, v_holdcnt =3D 0, v_useco=
unt =3D 0, v_iflag =3D 256, v_vflag =3D 0, v_writecount =3D 0,=20
>   v_freelist =3D {tqe_next =3D 0xc72c1c90, tqe_prev =3D 0xc8028d44}, v_bu=
fobj =3D {bo_mtx =3D 0xc6f043a8, bo_clean =3D {bv_hd =3D {
>         tqh_first =3D 0x0, tqh_last =3D 0xc6f043e4}, bv_root =3D 0x0, bv_=
cnt =3D 0}, bo_dirty =3D {bv_hd =3D {tqh_first =3D 0x0,=20
>         tqh_last =3D 0xc6f043f4}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_numo=
utput =3D 0, bo_flag =3D 0, bo_ops =3D 0xc09e8b84,=20
>     bo_bsize =3D 16384, bo_object =3D 0xc73b7bb8, bo_synclist =3D {le_nex=
t =3D 0x0, le_prev =3D 0x0}, bo_private =3D 0xc6f04324,=20
>     __bo_vnode =3D 0xc6f04324}, v_pollinfo =3D 0x0, v_label =3D 0x0}
> (kgdb) p *mp
> $2 =3D {mnt_lock =3D {lk_object =3D {lo_name =3D 0xc0940b6b "vfslock", lo=
_type =3D 0x0, lo_flags =3D 16777216, lo_witness_data =3D {
>         lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, lk_inter=
lock =3D 0xc0a37f58, lk_sharecount =3D 1, lk_waitcount =3D 0,=20
>     lk_exclusivecount =3D 0, lk_prio =3D 80, lk_timo =3D 0, lk_lockholder=
 =3D 0xffffffff, lk_newlock =3D 0x0}, mnt_mtx =3D {
>     mtx_object =3D {lo_name =3D 0xc0940b5a "struct mount mtx", lo_type =
=3D 0xc0940b5a "struct mount mtx", lo_flags =3D 16973824,=20
>       lo_witness_data =3D {lod_list =3D {stqe_next =3D 0xc0a478c8}, lod_w=
itness =3D 0xc0a478c8}}, mtx_lock =3D 3288279680,=20
>     mtx_recurse =3D 0}, mnt_gen =3D 1, mnt_list =3D {tqe_next =3D 0xc4335=
a70, tqe_prev =3D 0xc4336048}, mnt_op =3D 0xc09f4e60,=20
>   mnt_vfc =3D 0xc09f4ea0, mnt_vnodecovered =3D 0xc4338a78, mnt_syncer =3D=
 0xc43a4d9c, mnt_ref =3D 19648, mnt_nvnodelist =3D {
>     tqh_first =3D 0xc699a000, tqh_last =3D 0xc6fabca4}, mnt_nvnodelistsiz=
e =3D 19647, mnt_writeopcount =3D 1,=20
>   mnt_kern_flag =3D 536870916, mnt_flag =3D 2101248, mnt_noasync =3D 2, m=
nt_opt =3D 0xc4309770, mnt_optnew =3D 0x0,=20
>   mnt_maxsymlinklen =3D 120, mnt_stat =3D {f_version =3D 537068824, f_typ=
e =3D 5, f_flags =3D 2101248, f_bsize =3D 2048,=20
>     f_iosize =3D 16384, f_blocks =3D 5073731, f_bfree =3D 1746472, f_bava=
il =3D 1340574, f_files =3D 1318910, f_ffree =3D 883512,=20
>     f_syncwrites =3D 0, f_asyncwrites =3D 0, f_syncreads =3D 0, f_asyncre=
ads =3D 0, f_spare =3D {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},=20
>     f_namemax =3D 255, f_owner =3D 0, f_fsid =3D {val =3D {1157814914, -1=
754847891}}, f_charspare =3D '\0' <repeats 79 times>,=20
>     f_fstypename =3D "ufs", '\0' <repeats 12 times>, f_mntfromname =3D "/=
dev/ad0s2e", '\0' <repeats 76 times>,=20
>     f_mntonname =3D "/usr", '\0' <repeats 83 times>}, mnt_cred =3D 0xc43a=
5980, mnt_data =3D 0xc4333200, mnt_time =3D 0,=20
>   mnt_iosize_max =3D 131072, mnt_export =3D 0x0, mnt_mntlabel =3D 0x0, mn=
t_fslabel =3D 0x0, mnt_hashseed =3D 2485092944,=20
>   mnt_markercnt =3D 1, mnt_holdcnt =3D 1, mnt_holdcntwaiters =3D 0, mnt_s=
econdary_writes =3D 0, mnt_secondary_accwrites =3D 221216,=20
>   mnt_gjprovider =3D 0x0}
> (kgdb)=20

The vp looks like normal VI_FREE vnode. The interlock mutex is unowned.
The only strange thing is the
vp->v_interlock.mtx_object.lo_flags =3D 196608 =3D=3D 0x30000 =3D=3D
LO_INITIALIZED | LO_WITNESS. It misses 0x01000000 (LO_CLASSMASK bit) to
mark it as sleep mutex.

I suspected that the vnode is destroyed and somehow appeared on the mount
point list, but this is definitely not the case. Moreover, destroying lock
mutex (and lock object) would not clear the lo class bits.

Does anybody have further comments ?


--iRjOs3ViPWHdlw/I
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFdAaPC3+MBN1Mb4gRAiNHAJ9fUZoaLipZ6YYIieORIYMrqRDzwgCgtJGv
OiqNonDqGVezGazQ/I675Cs=
=2Djy
-----END PGP SIGNATURE-----

--iRjOs3ViPWHdlw/I--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061204112920.GJ35681>