Re: panic: LK_RETRY set with incompatible flags

From: Sergey Kandaurov <pluknet_at_gmail.com>
Date: Mon, 4 Feb 2013 16:41:00 +0300
On 4 February 2013 06:32, Rick Macklem <rmacklem_at_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

 1st 0xfffffe00b9569d50 zfs (zfs) _at_
/usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:884
 2nd 0xfffffe001dfd89a0 ufs (ufs) _at_ /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
Received on Mon Feb 04 2013 - 12:41:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:34 UTC