fsal_up: Fixed an issue in upcall "invalidate_close"

During cache_inode_entry invalidation upcall, make a synchronous
call of cache_inode_invalidate() only if there are no open/active fds
for the object handle of that entry.

Signed-off-by: Soumya Koduri <skoduri@redhat.com>
cache_inode: correct confusing log messages

Signed-off-by: Niels de Vos <ndevos@redhat.com>
Acked-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Acked-by: Soumya Koduri <skoduri@redhat.com>
Merge remote-tracking branch 'ndevos/trivial/logging/cache_inode_setattr' into next

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Merge remote-tracking branch 'remotes/skoduri/fsal_up' into next

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Convert FSAL_VFS/panfs to work with the new pnfs_device format.

The pnfs_device format recently changed to have structure in the first
64-bits, as opposed to storing an export ID in that field.  Convert the
panfs implementation in FSAL_VFS to use this new format.

Signed-off-by: Daniel Gryniewicz <dang@linuxbox.com>
Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Merge branch 'panfs' into next

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Use non-printable character instead of DOT for revoked file handles

Revoked delegation file handles are stored as a file name in the client
recovery directory by prefixing a "." to the base16 encoding of the file
handle. nfs4_clean_old_recov_dir() assumes that anything that starts
with "." inside base recovery directory is a revoked file handle but a
client specific recovery directory may have components that start with
"." as well.

This patch prefixes non-printable character '\x1' to the base16 encoding
of the revoked file handle to create file name. This should not conflict
with client recovery directory as it will have only printable
characters.

Also fixed nfs4_clean_old_recov_dir() to not make recursive calls on
revoked file handle names.  Also, removed an unneeded memset to 0.

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Reviewed-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Use continue to avoid extra indentation in nfs4_read_recov_clids()

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Reviewed-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
GPFSFSAL_symlink needs to ensure link type upon create.
Otherwise return EXIST.

Signed-off-by: Rong Zeng <rongzeng@us.ibm.com>
Signed-off-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Add base64 URL safe encoding function.

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Acked-by: Frank S. Filz <ffilzlnx@mindspring.com>
Use base64 URL safe encoding for revoked file handles

We create a file in recovery directory for a revoked file handle.  The
name of such created file is derived from the file handle.  If the file
handle contains only printable characters, we use the file handle as
file name. If it contains any non-printable characters, we use base16
encoding of the file handle as the file name. This conditional
conversion can result into two different file handles being stored as
the same file name. This is unlikely but possible! Also the maximum
length of the file handle can be 128 bytes based on NFSv4 RFC, but none
of the Ganesha FSAL's use more than 64 byte file handles at this time. A
128 byte file handle's base16 encoding will exceed NAME_MAX which is 255.

So this patch is really a future proof for Ganesha FSALs that may have
close to 128 byte length file handles as well as fixing that unlikely
file name collision!

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Acked-by: Frank S. Filz <ffilzlnx@mindspring.com>
Chck for CONFIG_MANDATORY

and return err on the first occurance.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Signed-off-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Merge remote-tracking branch 'remotes/ganltc/for_dev10' into next

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
V2.2-dev-10

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Fix usage of PATH_MAX

PATH_MAX includes the NUL byte. So any definition of the form
"char path[MAX_PATH+1]" is incorrect! It should just be "char
path[PATH_MAX]". Changed such definitions!

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Reviewed-by: Frank S. Filz <ffilzlnx@mindspring.com>