From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 13:36:18 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 1302F106566B for ; Sat, 27 Mar 2010 13:36:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BB9EE8FC18 for ; Sat, 27 Mar 2010 13:36:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABenrUuDaFvH/2dsb2JhbACbM3O+JIUBBA X-IronPort-AV: E=Sophos;i="4.51,319,1267419600"; d="scan'208";a="70171350" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Mar 2010 09:36:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id E96751084483; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0ExLLTdFuWB; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 8A0D01084444; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2RDnND14320; Sat, 27 Mar 2010 09:49:23 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 27 Mar 2010 09:49:23 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Petr Lampa In-Reply-To: <20100326162406.GA43912@fit.vutbr.cz> Message-ID: References: <20100326162406.GA43912@fit.vutbr.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org 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: Sat, 27 Mar 2010 13:36:18 -0000 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? > functions where nfsvno_namei() is called without SAVENAME|SAVESTART flags > also don't call nfsvno_relpathbuf(). Perhaps buffer should be initialized > with > > NFSNAMEICNDSET(&named.ni_cnd, nd->nd_cred, CREATE, LOCKPARENT | SAVENAME); > Yes, please try this. I think it will fix the problem, since my server code assumes that VOP_LOOKUP() will have set SAVENAME for the non-error case. (I don't think setting it is harmful and it will help isolate the problem further.) Please let us know how things go with SAVENAME set, as above. rick