From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 07:16:10 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 6BCE44BB; Tue, 5 Feb 2013 07:16:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 89422A81; Tue, 5 Feb 2013 07:16:09 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so3850623wid.6 for ; Mon, 04 Feb 2013 23:16:08 -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=u/B2vCbnOVvhSSOzvO5YBNAvfldMeB/9PI8vs4ZT5Qc=; b=iR/cPI6upN/yhHV3h3uqiVo9wQ4EPCqlkCJ7QStjwm7tTj3HEutFQS6lxPa+pvMP42 NvyQmuyxpjjI9AABB6uzLmm7nW55i+AM5jZXwerhLZeFDLXIJteun03o6enywtIErud3 Xc1aYLQQMxe65ENhJt67jduPPfcJSZaRywvmaSsiQ1KTqVNYR/aYwwmiODbxOtL9fjfw M2xEfrwL++iw5hmUgxpWa/QKEdy8S+OYjg0GherFysALKAMWySQQd5TAxphozS5R2XV1 /UGowWUGyB1QVTSe5LwnGgfMixCkWmFSLMEwdYyqdzsgrXOqVMASF7AB76Mg5RCGmflW cw4A== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr40121070wjc.3.1360048568488; Mon, 04 Feb 2013 23:16:08 -0800 (PST) Received: by 10.195.12.163 with HTTP; Mon, 4 Feb 2013 23:16:08 -0800 (PST) In-Reply-To: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> References: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 5 Feb 2013 10:16:08 +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: Tue, 05 Feb 2013 07:16:10 -0000 On 5 February 2013 04:13, Rick Macklem wrote: > 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? On server (with unmodified kernel): # ls -la /pool1/user1001/.zfs/share total 2 dr-xr-xr-x 2 root wheel 2 Feb 2 20:06 . dr-xr-xr-x 4 root wheel 4 Feb 2 20:06 .. It crashes only when .zfs/share is accessed via NFS (with and without snapshots), and not when accessed locally. -- wbr, pluknet