From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 00:14:21 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 A4A72ABA; Tue, 5 Feb 2013 00:14:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22517A5B; Tue, 5 Feb 2013 00:14:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIFOEFGDaFvO/2dsb2JhbABFhki5EnOCHwEBBAEjBFIFFg4KAgINGQJZBhOICwapH5JDgSOPHIETA4hmjTmJVYZ8gxqCBg X-IronPort-AV: E=Sophos;i="4.84,602,1355115600"; d="scan'208";a="12427217" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Feb 2013 19:13:50 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1C079B3F17; Mon, 4 Feb 2013 19:13:50 -0500 (EST) Date: Mon, 4 Feb 2013 19:13:50 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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: Tue, 05 Feb 2013 00:14:21 -0000 Sergey Kandaurov wrote: > 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 > Yes, I think the patch is relatively safe, since lookup() checks for same vnode and does a vrele() instead of a vput() when they are the same, at least for a plain lookup without wantparent. So, since I've never used ZFS, what does a "ls -la /home/user1001/.zfs/shares/" give you when done locally one the server? > 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 --- > I don't think this LOR is an issue. It definitely isn't related to the panic/crash. Thanks for collecting this information and passing it along, rick > > -- > wbr, > pluknet