From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 13:41:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 935FF80A; Mon, 4 Feb 2013 13:41:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 57E6E1C75; Mon, 4 Feb 2013 13:41:01 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id o25so7941683iad.5 for ; Mon, 04 Feb 2013 05:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T9EHwgEq6i4XJlNNdIq4C/uMzgKuBEHaVI/j2ul5t7M=; b=YW0GxhsDIWYoYtXhce+JbJC+jfeHD51XEcT4rUobKITWpZ6DGM+UDy4H3yio9H4+ib /jsl3wzkXH33o7d7LNptQkTkEYPqTr07V2UExqCDE5yjUgq1ev4+Sg3TPV1ijAwKrm5w XgVg3QGc92JSaMK+IUhFdh2FJmZ45xTwya9fgHH8t1c9GX4WqygDIG10iyCV3w1ViRdb mfnkL9z1nN2osI6djvO7NtTLHJTf9hS/CgdOqtjHK5tY++8miN4vt48n1wiRZXPOTVje AFv29VXAe4u1HB3mrQr7KilupXAMpxf8u6ZUj+0eqPqa1FW0k76+e+8fC2EW1YB+2Cz7 BytA== MIME-Version: 1.0 X-Received: by 10.50.155.134 with SMTP id vw6mr6507082igb.34.1359985261027; Mon, 04 Feb 2013 05:41:01 -0800 (PST) Received: by 10.64.29.13 with HTTP; Mon, 4 Feb 2013 05:41:00 -0800 (PST) In-Reply-To: <2051134267.2641928.1359945139386.JavaMail.root@erie.cs.uoguelph.ca> References: <20130203110759.GM2522@kib.kiev.ua> <2051134267.2641928.1359945139386.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 4 Feb 2013 16:41:00 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , FreeBSD Current , 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: Mon, 04 Feb 2013 13:41:01 -0000 On 4 February 2013 06:32, Rick Macklem wrote: > Konstantin Belousov wrote: >> 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. > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) { > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; > 390 > 391 /* > 392 * If we are a snapshot mounted under .zfs, return > 393 * the vp for the snapshot directory. > 394 */ > 395 if ((error = sa_lookup(dzp->z_sa_hdl, > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) > 397 return (error); > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, > 400 "snapshot", vpp, NULL, 0, NULL, kcred, > 401 NULL, NULL, NULL); > 402 return (error); > 403 } > > Just reading the comment, I don't know what it is referring to by > "snapshot directory". Would that be "shares" for Sergey's case? > > It seems too obvious, but maybe the lookup of ".." is returning the > vnode for /.zfs/shares for this case? > > I don't know why this wouldn't have shown up before, but maybe it usually > replies from its cache (I think zfs_lookup() calls it a "fast path"). > > It might still be interesting to replace zfs_vnops.c line# 1451 with: > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > and see what happens? > With this change `ls /home/user1001/.zfs/shares/' lists empty directory (although the relevant dataset has snapshot, but that's a different story :)). Great! Nothing panics/asserts/etc, just seemingly unrelated LOR 1st 0xfffffe00b9569d50 zfs (zfs) @ /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:884 2nd 0xfffffe001dfd89a0 ufs (ufs) @ /usr/src/sys/kern/vfs_vnops.c:461 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff848e709d00 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff848e709db0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff848e709e30 __lockmgr_args() at __lockmgr_args+0x6c9/frame 0xffffff848e709f60 ffs_lock() at ffs_lock+0x84/frame 0xffffff848e709fb0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e709fd0 _vn_lock() at _vn_lock+0xab/frame 0xffffff848e70a040 vn_rdwr() at vn_rdwr+0x1f1/frame 0xffffff848e70a100 nfsrv_writestable() at nfsrv_writestable+0xbe/frame 0xffffff848e70a170 nfsrv_openupdate() at nfsrv_openupdate+0x489/frame 0xffffff848e70a5d0 nfsrvd_openconfirm() at nfsrvd_openconfirm+0x123/frame 0xffffff848e70a6b0 nfsrvd_dorpc() at nfsrvd_dorpc+0xf9a/frame 0xffffff848e70a8a0 nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e70aa00 svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e70aba0 svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e70abb0 fork_exit() at fork_exit+0x84/frame 0xffffff848e70abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e70abf0 --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = 0x7fffffffd970 --- -- wbr, pluknet