Possible error in nfs_nfsdserv.c?
jhb at freebsd.org
Mon Mar 29 16:16:47 UTC 2010
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
> > 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.
More information about the freebsd-current