In cases where some dirs are created directly on the backend, either by users or by the disk FS like the lost+found dir, these new dirs do not contain the GFID attr. NFS gets a zero-ed out iatt->ia_gfid in such case. Because the hash for this gfid will be 0, it ends up matching a directory whose hash may be zero. ANother situation is when the 0 hash is compared to a hash value beyond the hash idx in the FH resulting in a successful hash match. Eventually, it causes an ESTALE because we ended up taking the wrong dir path. Simple solution is to use a salt value when computing the hash.
Been looking into this bug and I think we should leave this out of 3.1.3. The addition of a salt value will change the encoding scheme of the FH. If a user upgrades from 3.1.2 to 3.1.3, the nfs clients will start receiving ESTALE because the nfs server will not recognize the old file handles. In effect, this bug is similar to bug 763781. *** This bug has been marked as a duplicate of bug 2049 ***