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 BaldwinReceived on Mon Mar 29 2010 - 14:16:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC