On Sun, 15 Feb 2015 23:28:12 -0500 Trond Myklebust
<trond.myklebust@xxxxxxxxxxxxxxx> wrote:
> On Sun, Feb 15, 2015 at 9:46 PM, NeilBrown <neilb@xxxxxxx> wrote:
> > On Sat, 14 Feb 2015 13:17:00 +0000 Nix <nix@xxxxxxxxxxxxx> wrote:
> >
> >> On 10 Feb 2015, J. Bruce Fields outgrape:
> >>
> >> > It might be interesting to see output from
> >> >
> >> > rpc.debug -m rpc -s cache
> >> > cat /proc/net/rpc/nfsd.export/content
> >> > cat /proc/net/rpc/nfsd.fh/content
> >> >
> >> > especially after the problem manifests.
> >>
> >> So the mount has vanished again. I couldn't make it happen with
> >> nordirplus in the mount options, so that might provide you with a clue.
> >
> > Yup. It does.
> >
> > There is definitely something wrong in nfs_prime_dcache. I cannot quite
> > trace through from cause to effect, but maybe I don't need to.
> >
> > Can you try the following patch and see if that makes the problem disappear?
> >
> > When you perform a READDIRPLUS request on a directory that contains
> > mountpoints, the the Linux NFS server doesn't return a file-handle for
> > those names which are mountpoints (because doing so is a bit tricky).
> >
> > nfs3_decode_dirent notices and decodes as a filehandle with zero length.
> >
> > The "nfs_same_file()" check in nfs_prime_dcache() determines that isn't
> > the same as the filehandle it has, and tries to invalidate it and make a new
> > one.
> >
> > The invalidation should fail (probably does).
> > The creating of a new one ... might succeed. Beyond that, it all gets a bit
> > hazy.
> >
> > Anyway, please try:
> >
> > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> > index 9b0c55cb2a2e..a460669dc395 100644
> > --- a/fs/nfs/dir.c
> > +++ b/fs/nfs/dir.c
> > @@ -541,7 +541,7 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc, struct nfs_entry *en
> >
> > count++;
> >
> > - if (desc->plus != 0)
> > + if (desc->plus != 0 && entry->fh.size)
> > nfs_prime_dcache(desc->file->f_path.dentry, entry);
> >
> > status = nfs_readdir_add_to_array(entry, page);
> >
> >
> > which you might have to apply by hand.
>
> Doesn't that check ultimately belong in nfs_fget()? It would seem to
> apply to all filehandles, irrespective of provenance.
>
Maybe. Though I think it also needs to be before nfs_prime_dcache() tries to
valid the dentry it found.
e.g.
if (dentry != NULL) {
if (entry->fh->size == 0)
goto out;
else if (nfs_same_file(..)) {
....
else {
d_invalidate();
...
}
}
??
I'd really like to understand what is actually happening though.
d_invalidate() shouldn't effect an unmount.
Maybe the dentry that gets mounted on is the one with the all-zero fh...
NeilBrown
Attachment:
pgpwe6BwOOaZK.pgp
Description: OpenPGP digital signature
