If we get a ESTALE on readdir retry the dirent
as we might have hit with a old dirent which we kept for
performance reasons

Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Signed-off-by: Rong Zeng <rongzeng@us.ibm.com>
cache_inode_add_cached_dirent should return reused dirent
inaddition to just copying it.

Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Fix OPNDG10

Two issues:

1. OPEN CREATE UNGUARDED did not reuse existing state
2. state_share_upgrade did not create union of old access and new access

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Fix OPEN30

For open replay, we need to track the directory cache entry pointer not
the resulting file cache entry pointer.

The entry is saved by Copy_nfs4_state_req and checked by
Check_nfs4_seqid when validating a replayed request.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Fix COMP5 for NFS v4.1

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Fix a problem uncovered by RNM20

Rename of file to a hard link to the file is directed by the RFCs to
do nothing. Code was not correctly handling and causing the "from"
name to be removed from Ganesha's directory cache.

The scenario in question is caused by the following sequence:

echo foo > /mnt4/file
ln /mnt4/file /mnt4/link
mv /mnt4/file /mnt4/link

It would appear that that should result in just one hard link to
the inode, named /mnt4/link, however, the RFCs specify that this
is a no-op operation, which means the file remains with two hard
links.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Properly fix CLOSE4

It turns out Ganesha really wasn't handling a CLOSE with an invalid
stateid properly. If we detect that the stateid belongs to a valid
clientid, we can return NFS4_OK, but in that case, we must also
update the lease.

We also need to make sure that ONLY CLOSE is affected by this
functionality. V4.1 also handles leases differently.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
Clean the progress status  dir bfore starting ganesha.

Signed-off-by: Srikrishan Malik <srimalik@in.ibm.com>
Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>