Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jun 2009 14:51:54 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Dag-Erling Sm??rgrav <des@des.no>
Cc:        current@freebsd.org
Subject:   Re: LOR between NFS and syncer
Message-ID:  <20090606115154.GI1927@deviant.kiev.zoral.com.ua>
In-Reply-To: <86skief8q6.fsf@ds4.des.no>
References:  <86skief8q6.fsf@ds4.des.no>

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

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

On Sat, Jun 06, 2009 at 03:32:01AM +0200, Dag-Erling Sm??rgrav wrote:
> Anyone seen this one before?
>=20
> NFS+ZFS server, diskless NFS client.  Both run head.  On the client:
>=20
> lock order reversal:
>  1st 0xc301c164 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693
>  2nd 0xc322c058 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2083
> KDB: stack backtrace:
> db_trace_self_wrapper(c07477c6,c2bbfa18,c05921c5,c058310b,c074a615,...) a=
t db_trace_self_wrapper+0x26
> kdb_backtrace(c058310b,c074a615,c2cb0828,c2cb0688,c2bbfa74,...) at kdb_ba=
cktrace+0x29
> _witness_debugger(c074a615,c322c058,c0759e62,c2cb0688,c0750f5e,...) at _w=
itness_debugger+0x25
> witness_checkorder(c322c058,9,c0750f5e,823,0,...) at witness_checkorder+0=
x839
> __lockmgr_args(c322c058,80500,c322c074,0,0,...) at __lockmgr_args+0x797
> vop_stdlock(c2bbfb88,c2bbfb70,c0591f6b,c0750f5e,c073ced7,...) at vop_stdl=
ock+0x62
> VOP_LOCK1_APV(c079d720,c2bbfb88,c0750f5e,c07b5100,c322c000,...) at VOP_LO=
CK1_APV+0xf3
> _vn_lock(c322c000,80500,c0750f5e,823,df,...) at _vn_lock+0x5e
> vget(c322c000,80500,c2f1f480,c6e,c2f35c94,...) at vget+0xb9
> vfs_msync(c2f35c94,2,c0750f5e,d67,c2f35c94,...) at vfs_msync+0xe7
> sync_fsync(c2bbfc7c,c301c10c,80400,c0750f5e,69d,...) at sync_fsync+0x17b
> VOP_FSYNC_APV(c07975c0,c2bbfc7c,c0750f5e,69d,c2f1f480,...) at VOP_FSYNC_A=
PV+0xda
> sync_vnode(c093d8f0,c093d8dc,3e8,6cc,4e20,...) at sync_vnode+0x168
> sched_sync(0,c2bbfd38,c073fcec,334,c2ceea90,...) at sched_sync+0x273
> fork_exit(c05d8570,0,c2bbfd38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip =3D 0, esp =3D 0xc2bbfd70, ebp =3D 0 ---

We lock the covered vnode when doing mount or unmount for the non-root
filesystem. Since witness works by recording order by lock name, we get
the order of mounted on -> mounted from vnode type. Thus, any interleave
in the mount type would give us a LOR.

The vnode list for the mount point also includes syncer vnode, that
has a special fsync vop. Usual order is syncer vnode lock -> vnode
lock for the real vnodes. But, when filesystem is unmounted, we get
the order covered vnode -> any filesystem vnode during sync before
unmount. This one gives the LOR you reported, assuming you unmounted
nfs share mounted on the top of nfs share.

I think both issues cannot result in a deadlock.

--ICd5mx19QJ1U62fT
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAkoqWFoACgkQC3+MBN1Mb4hdjwCg2Mxfb84KWnmM2IBKoSv2hJBm
ZV8An1kEadbLUXxSBAiO+pgAbCLHDzDy
=K9Yo
-----END PGP SIGNATURE-----

--ICd5mx19QJ1U62fT--



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