From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 16:16:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1911065675 for ; Mon, 29 Mar 2010 16:16:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF158FC1B for ; Mon, 29 Mar 2010 16:16:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C1A2D46BA4; Mon, 29 Mar 2010 12:16:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D3B158A01F; Mon, 29 Mar 2010 12:16:45 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Mar 2010 12:16:23 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100326162406.GA43912@fit.vutbr.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003291216.23887.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 29 Mar 2010 12:16:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Petr Lampa , Rick Macklem Subject: Re: Possible error in nfs_nfsdserv.c? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2010 16:16:47 -0000 On Saturday 27 March 2010 9:49:23 am Rick Macklem wrote: > > On Fri, 26 Mar 2010, Petr Lampa wrote: > > > > > I've got several "panic: nfsrelpath", see attached photo. I've found > > one place where it could probably happen, please, can you look at this? > > > > First name buffer is initialized in nfsrvd_link() with: > > NFSNAMEICNDSET(&named.ni_cnd, nd->nd_cred, CREATE, LOCKPARENT); > > > > Then: > > nd->nd_repstat = nfsvno_namei(nd, &named, dp, 0, &tnes, > > p, &dirp); > > > > and > > nd->nd_repstat = nfsvno_link(&named, vp, nd->nd_cred, p, exp); > > > > is called. The nfsvno_link() calls nfsvno_relpathbuf() unconditionally, > > this is the place where the panic happened. The only place where buffer can > > be released in no error case is in the nfsvno_namei(). There is a call > > > > if ((cnp->cn_flags & (SAVENAME | SAVESTART)) == 0) > > nfsvno_relpathbuf(ndp); > > > > there and no SAVENAME|SAVESTART is set in NFSNAMEICNDSET(). But if > > buffer is alwyas released at this place, then link would be panicing also > > always (and it isn't). So probably I'm missing something here. Other > > For ufs, ufs_lookup() sets SAVENAME for the CREATE case, which is why > I don't see such a panic. I had thought that all file systems would do > this for VOP_LOOKUP() for CREATE. It sounds like you've found a case > where that isn't happening. Could you please tell us what file system > type is being accessed when this panic occurs? > > I've cc'd freebsd-current, so that anyone conversant with the FreeBSD > VFS can jump in here. Am I right to assume that VOP_LOOKUP() for CREATE > will set SAVENAME when returning error == 0? No, the caller has to set that flag. Some filesystems set it internally to force the name to be saved (e.g. the NFS client), but there is nothing in the VFS layer itself that sets it that I can see. -- John Baldwin