On Thu, Nov 29, 2012 at 04:57:19PM -0800, Patrick McLean wrote: > > Interesting... Server-side that should've been produced by > > encode_entryplus_baggage(), which looks like failing compose_entry_fh()... > > which has explicit > > if (d_mountpoint(dchild)) > > goto out; > > resulting in ENOENT on everything that's overmounted on server. > > > > Do you, by any chance, have the server really exporting its own root > > filesystem? Another thing to check: have nfs_prime_dcache() print > > filename.name of everything that fails nfs_same_entry() and has > > zero entry->fh->size, regardless of d_invalidate() results. > > The server is running 3.6.6 and is just exporting a subdir of an xfs filesystem (which does not happen to be the root filesystem). > > The client is running as a KVM guest on the machine that is serving the NFS. I am reproducing this by booting the guest via an initramfs, and doing > "ls /" at in single user mode. > > I added a check that prints the filename.name of everything that fails nfs_same_file, and it appears to just be triggered by the same filesystems that > are triggering the WARN_ON, the relevant dmesg is below. [the same /dev, /proc and /sys] Very interesting. Do you have anything mounted on the corresponding directories on server? The picture looks like you are getting empty fhandles in readdir+ respons for exactly the same directories that happen to be mountpoints on client. In any case, we shouldn't do that blind d_drop() - empty fhandles can happen. The only remaining question is why do they happen on that set of entries. From my reading of encode_entryplus_baggage() it looks like we have compose_entry_fh() failing for those entries and those entries alone. One possible cause would be d_mountpoint(dchild) being true on server. If it is true, we can declare the case closed; if not, I really wonder what's going on. Note that if the same fs is mounted elsewhere, d_mountpoint() would mean that something is mounted on top of that directory in _some_ instance; not necessary the exported one. Can you slap printks on fs/nfsd/nfs3xdr.c compose_entry_fh() failure exits and see which one triggers server-side? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html