From owner-freebsd-current@FreeBSD.ORG Thu Jan 31 13:37:40 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 DB9A0D3C for ; Thu, 31 Jan 2013 13:37:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6277CF for ; Thu, 31 Jan 2013 13:37:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA08400; Thu, 31 Jan 2013 15:37:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510A73A0.9000607@FreeBSD.org> Date: Thu, 31 Jan 2013 15:37:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: panic: LK_RETRY set with incompatible flags References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current 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: Thu, 31 Jan 2013 13:37:40 -0000 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) == 0 || error == 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 LK_SHARED, not LK_UPGRADE. Apparently the thread already holds an exlusive lock on the vnode, which you confirm below. > 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 = 0x800883e9a, rsp = 0x7fffffffd488, rbp = 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) > > > -- Andriy Gapon