From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 11:08:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 15ADE45F; Sun, 3 Feb 2013 11:08:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2C1229; Sun, 3 Feb 2013 11:08:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r13B7x88009350; Sun, 3 Feb 2013 13:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r13B7x88009350 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r13B7xjk009349; Sun, 3 Feb 2013 13:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Feb 2013 13:07:59 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags Message-ID: <20130203110759.GM2522@kib.kiev.ua> References: <510A73A0.9000607@FreeBSD.org> <1423598176.2627168.1359858639862.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yHpupmvcyB3InP4W" Content-Disposition: inline In-Reply-To: <1423598176.2627168.1359858639862.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , Sergey Kandaurov , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 03 Feb 2013 11:08:05 -0000 --yHpupmvcyB3InP4W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > Andriy Gapon wrote: > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > > Hi. > > > > > > Got this assertion on idle NFS server while `ls -la /.zfs/shares/' > > > issued on NFS client. > > > kern/vfs_vnops.c:_vn_lock() > > > KASSERT((flags & LK_RETRY) =3D=3D 0 || error =3D=3D 0, > > > ("LK_RETRY set with incompatible flags (0x%x) or > > > an error occured (%d)", > > > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an error > > > occured (11) > > > > > > What does that mean and how is it possible? As you can see, both > > > parts > > > of assertion failed. > > > 11 is EDEADLK > > > 0x200400: LK_RETRY & LK_UPGRADE > >=20 > > LK_SHARED, not LK_UPGRADE. > > Apparently the thread already holds an exlusive lock on the vnode, > > which you > > confirm below. > >=20 > >=20 > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > > 0xffffff848e45f240 > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > > 0xffffff848e45f260 > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e45f2b0 > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > > nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e45fa00 > > > svc_run_internal() at svc_run_internal+0x1e9/frame > > > 0xffffff848e45fba0 > > > svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e45fbb0 > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e45fbf0 > > > --- trap 0xc, rip =3D 0x800883e9a, rsp =3D 0x7fffffffd488, rbp =3D > > > 0x7fffffffd730 --- > > > > > > db> show lockedvnods > > > Locked vnodes > > > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > > flags (VI_ACTIVE) > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > > nfsd, > > > tid 101532) > > > > > > > > > > I just took a look at zfs_vnops.c and I am probably missing something, > but I can't see how this ever worked for a lookup of ".." when at the > root (unless ZFS doesn't do the ".." is the current directory when at > the root). >=20 > Here's the code snippet: > 1442 if (error =3D=3D 0 && (nm[0] !=3D '.' || nm[1] !=3D '\0')) { > 1443 int ltype =3D 0; > 1444 =09 > 1445 if (cnp->cn_flags & ISDOTDOT) { > 1446 ltype =3D VOP_ISLOCKED(dvp); > 1447 VOP_UNLOCK(dvp, 0); > 1448 } > 1449 ZFS_EXIT(zfsvfs); > 1450 error =3D zfs_vnode_lock(*vpp, cnp->cn_lkflags); > 1451 if (cnp->cn_flags & ISDOTDOT) > 1452 vn_lock(dvp, ltype | LK_RETRY); > 1453 if (error !=3D 0) { > 1454 VN_RELE(*vpp); > 1455 *vpp =3D NULL; > 1456 return (error); > 1457 }=20 >=20 > Maybe line# 1451 should be changed to: > if ((cnp->cn_flags & ISDOTDOT) && *vpp !=3D dvp) >=20 > I'm not at all familiar with ZFS, so I've probably way > off the mark on this, rick > ps: I hope kib and jhb don't mind being added as cc's, since > they are familiar with this stuff, although maybe not ZFS > specifics. VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. The logic in the lookup() prevents it. Might it be a missing check in the nfs server code ? (I did not looked yet). --yHpupmvcyB3InP4W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDkUPAAoJEJDCuSvBvK1BaRsP/jK3Y+hIYByw8IwzsWlm1wzo OXzYznH6HOjp5D4zijl4efx1UiPUYw8FnxLEwUol2hHH8Nkplj7lv1DkaAIHekoC bRJ/G8+lyJXKZlY9cKMPrZrzGFAwUtxMwZbXTIbfOIjemji1GgtxDmQVSQu0xotW wU+ae2fNmCdS6+/9rRyKQId1w/M02oZOO3cleoaoFmGI8kVYgYpZ6jHtg0twK3K8 fFLq486TLx/MFX8iUzVrbe5T1h4q+tOENtcDz4xxO4b7P7S34Tb1Z3ZDKl7CEpxy vjIuu9/4tXuivuyBiJgXQx8Tv5nfOxF7+jPzpbizj56Ggg4xSSdmr68oh3mWoESG JzeupNk6B/WfBfTA26jKi82lFVGuhm+kIj/KNxHGbOHSIApKHKTvWAt9Vy4vj+fo E3f0EP3qXpsF856ux9hAeVyQuUMprFcN/XkCNANyiqdeq0H0/rSgFaqoO3JE7Pfw aC+4l7uwhNplK4rW4MHFL/26AbAEVzNKZcp9zuwAWSv45hakH0EdAyJaPpXCc41a bYvnmL57oln95d/TjdbI6WW9nbJRKZNEr1r4A4+eKZiOS85AZL277e5dxo34dj+D SHJHt/GTDpH3YM00uZuQj6yI6EHu/DVD8spgUDIpvaLwRrxY/1HZgMJcD/dmrwRs nOuhTGDNKp0/WNOPtQX/ =9ruN -----END PGP SIGNATURE----- --yHpupmvcyB3InP4W--