Date: Mon, 4 Feb 2013 19:13:50 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Sergey Kandaurov <pluknet@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: panic: LK_RETRY set with incompatible flags Message-ID: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <CAE-mSOLA2J6KteFM-NH9Lb9TfX3rykckkMjguZMQFg4oLx-mWQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sergey Kandaurov wrote:
> On 4 February 2013 06:32, Rick Macklem <rmacklem@uoguelph.ca> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1105316997.2683638.1360023230093.JavaMail.root>