1. 06 6月, 2012 1 次提交
    • T
      NFS: Fix a commit bug · 9bce008b
      Trond Myklebust 提交于
      The new commit code fails to copy the verifier into the wb_verf field
      of _all_ the nfs_page structures; it only copies it into the first entry.
      The consequence is that most requests end up failing to match in
      nfs_commit_release.
      
      Fix is to copy the verifier into the req->wb_verf field in
      nfs_write_completion.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Fred Isaman <iisaman@netapp.com>
      9bce008b
  2. 05 6月, 2012 1 次提交
    • T
      NFSv4: Fix an Oops in the open recovery code · 1549210f
      Trond Myklebust 提交于
      The open recovery code does not need to request a new value for the
      mdsthreshold, and so does not allocate a struct nfs4_threshold.
      The problem is that encode_getfattr_open() will still request an
      mdsthreshold, and so we end up Oopsing in decode_attr_mdsthreshold.
      
      This patch fixes encode_getfattr_open so that it doesn't request an
      mdsthreshold when the caller isn't asking for one. It also fixes
      decode_attr_mdsthreshold so that it errors if the server returns
      an mdsthreshold that we didn't ask for (instead of Oopsing).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      1549210f
  3. 27 5月, 2012 1 次提交
  4. 25 5月, 2012 2 次提交
  5. 23 5月, 2012 4 次提交
  6. 02 5月, 2012 4 次提交
  7. 01 5月, 2012 1 次提交
  8. 28 4月, 2012 13 次提交
  9. 21 4月, 2012 1 次提交
  10. 21 3月, 2012 4 次提交
  11. 03 3月, 2012 2 次提交
    • C
      NFS: Request fh_expire_type attribute in "server caps" operation · 264e6351
      Chuck Lever 提交于
      The fh_expire_type file attribute is a filesystem wide attribute that
      consists of flags that indicate what characteristics file handles
      on this FSID have.
      
      Our client doesn't support volatile file handles.  It should find
      out early (say, at mount time) whether the server is going to play
      shenanighans with file handles during a migration.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      264e6351
    • C
      NFS: Introduce NFS_ATTR_FATTR_V4_LOCATIONS · 81934ddb
      Chuck Lever 提交于
      The Linux NFS client must distinguish between referral events (which
      it currently supports) and migration events (which it does not yet
      support).
      
      In both types of events, an fs_locations array is returned.  But upper
      layers, not the XDR layer, should make the distinction between a
      referral and a migration.  There really isn't a way for an XDR decoder
      function to distinguish the two, in general.
      
      Slightly adjust the FATTR flags returned by decode_fs_locations()
      to set NFS_ATTR_FATTR_V4_LOCATIONS only if a non-empty locations
      array was returned from the server.  Then have logic in nfs4proc.c
      distinguish whether the locations array is for a referral or
      something else.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      81934ddb
  12. 02 3月, 2012 1 次提交
  13. 15 2月, 2012 1 次提交
  14. 04 2月, 2012 1 次提交
    • T
      NFSv4: Fix an Oops in the NFSv4 getacl code · 331818f1
      Trond Myklebust 提交于
      Commit bf118a34 (NFSv4: include bitmap
      in nfsv4 get acl data) introduces the 'acl_scratch' page for the case
      where we may need to decode multi-page data. However it fails to take
      into account the fact that the variable may be NULL (for the case where
      we're not doing multi-page decode), and it also attaches it to the
      encoding xdr_stream rather than the decoding one.
      
      The immediate result is an Oops in nfs4_xdr_enc_getacl due to the
      call to page_address() with a NULL page pointer.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      Cc: stable@vger.kernel.org
      331818f1
  15. 01 2月, 2012 2 次提交
  16. 08 1月, 2012 1 次提交
    • T
      NFSv4: Save the owner/group name string when doing open · 6926afd1
      Trond Myklebust 提交于
      ...so that we can do the uid/gid mapping outside the asynchronous RPC
      context.
      This fixes a bug in the current NFSv4 atomic open code where the client
      isn't able to determine what the true uid/gid fields of the file are,
      (because the asynchronous nature of the OPEN call denies it the ability
      to do an upcall) and so fills them with default values, marking the
      inode as needing revalidation.
      Unfortunately, in some cases, the VFS will do some additional sanity
      checks on the file, and may override the server's decision to allow
      the open because it sees the wrong owner/group fields.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6926afd1