[ewg] [GIT PULL OFED-1.5] NFSRDMA bug fixes

[Jon Mason]

Hey Vlad,
Please pull from

ssh://vlad@sofa.openfabrics.org/home/jon/scm/ofed_kernel-1.5.git dev

It contains the following patches:

commit bf88ed67cb39869c1599af5be7d77425a2cbab45
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Aug 6 16:50:07 2009 -0500

    Getting Stale NFS file handles when running NFS tests on XFS (regardless
    of RDMA and transport).  I have determined the root of the problem to be
    the encoding/decoding of the file handle.  While other file systems have
    functions to encode the file handle, most simply copy the existing
    struct into the memory NFS provides.  When getting the dentry, they
    reference the memory in the way that the struct is.  However, XFS
    encodes by writing all of the relevant info into an array (not they way
    it is stored in the struct).  Thus, the decode function must be called
    (which was not necessary for the others based on their simplicity).  The
    decode method for xfs calls sb->s_export_op->find_exported_dentry(), so
    this must be set prior to any calls.  This was done in the original
    version of the NFS code in 2.6.22.  This issue only seems to affect
    kernels 2.6.22 and older.
    
    This patch fixes RHEL5.2
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>

commit 4c3fe1ff8d9f114b98e022f86bbeaef7303314cc
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Aug 6 16:48:04 2009 -0500

    Getting Stale NFS file handles when running NFS tests on XFS (regardless
    of RDMA and transport).  I have determined the root of the problem to be
    the encoding/decoding of the file handle.  While other file systems have
    functions to encode the file handle, most simply copy the existing
    struct into the memory NFS provides.  When getting the dentry, they
    reference the memory in the way that the struct is.  However, XFS
    encodes by writing all of the relevant info into an array (not they way
    it is stored in the struct).  Thus, the decode function must be called
    (which was not necessary for the others based on their simplicity).  The
    decode method for xfs calls sb->s_export_op->find_exported_dentry(), so
    this must be set prior to any calls.  This was done in the original
    version of the NFS code in 2.6.22.  This issue only seems to affect
    kernels 2.6.22 and older.
    
    This patch fixes RHEL5.3
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>

commit 417ff3ab1639878aabd6bf13c54277c94226e3b5
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Aug 6 16:45:21 2009 -0500

    Getting Stale NFS file handles when running NFS tests on XFS (regardless
    of RDMA and transport).  I have determined the root of the problem to be
    the encoding/decoding of the file handle.  While other file systems have
    functions to encode the file handle, most simply copy the existing
    struct into the memory NFS provides.  When getting the dentry, they
    reference the memory in the way that the struct is.  However, XFS
    encodes by writing all of the relevant info into an array (not they way
    it is stored in the struct).  Thus, the decode function must be called
    (which was not necessary for the others based on their simplicity).  The
    decode method for xfs calls sb->s_export_op->find_exported_dentry(), so
    this must be set prior to any calls.  This was done in the original
    version of the NFS code in 2.6.22.  This issue only seems to affect
    kernels 2.6.22 and older.
    
    This patch fixes RHEL5.4
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>

commit d7e621cf873d9a00521d15f9e7bfe605cabde6a3
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Aug 6 15:29:04 2009 -0500

    Getting Stale NFS file handles when running NFS tests on XFS (regardless
    of RDMA and transport).  I have determined the root of the problem to be
    the encoding/decoding of the file handle.  While other file systems have
    functions to encode the file handle, most simply copy the existing
    struct into the memory NFS provides.  When getting the dentry, they
    reference the memory in the way that the struct is.  However, XFS
    encodes by writing all of the relevant info into an array (not they way
    it is stored in the struct).  Thus, the decode function must be called
    (which was not necessary for the others based on their simplicity).  The
    decode method for xfs calls sb->s_export_op->find_exported_dentry(), so
    this must be set prior to any calls.  This was done in the original
    version of the NFS code in 2.6.22.  This issue only seems to affect
    kernels 2.6.22 and older.
    
    This patch fixes SLES10sp2
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>

commit e9b3ca8f9056d25971f29793cc8d31c8af22c6a3
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Aug 6 10:26:24 2009 -0500

    Getting Stale NFS file handles when running NFS tests on XFS (regardless
    of RDMA and transport).  I have determined the root of the problem to be
    the encoding/decoding of the file handle.  While other file systems have
    functions to encode the file handle, most simply copy the existing
    struct into the memory NFS provides.  When getting the dentry, they
    reference the memory in the way that the struct is.  However, XFS
    encodes by writing all of the relevant info into an array (not they way
    it is stored in the struct).  Thus, the decode function must be called
    (which was not necessary for the others based on their simplicity).  The
    decode method for xfs calls sb->s_export_op->find_exported_dentry(), so
    this must be set prior to any calls.  This was done in the original
    version of the NFS code in 2.6.22.  This issue only seems to affect
    kernels 2.6.22 and older.
    
    This patch fixes 2.6.22
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>

commit 9bb82e32e616d17ce5ad6278442718b1262167ec
Author: Jon Mason <jon at opengridcomputing.com>
Date:   Thu Jul 30 14:30:32 2009 -0500

    RHEL5.4 does not need the genalloc shim due to the genalloc code being
    exported and accessable in this release.
    
    Signed-Off-By: Jon Mason <jon at opengridcomputing.com>


Thanks,
Jon