1. 21 3月, 2012 3 次提交
  2. 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
  3. 02 3月, 2012 1 次提交
  4. 15 2月, 2012 1 次提交
  5. 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
  6. 01 2月, 2012 2 次提交
  7. 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
  8. 05 1月, 2012 1 次提交
    • A
      NFSv4: include bitmap in nfsv4 get acl data · bf118a34
      Andy Adamson 提交于
      The NFSv4 bitmap size is unbounded: a server can return an arbitrary
      sized bitmap in an FATTR4_WORD0_ACL request.  Replace using the
      nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
      with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
      xdr length to the (cached) acl page data.
      
      This is a general solution to commit e5012d1f "NFSv4.1: update
      nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
      when getting ACLs.
      
      Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
      was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.
      
      Cc: stable@kernel.org
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bf118a34
  9. 05 11月, 2011 1 次提交
    • J
      nfs: when attempting to open a directory, fall back on normal lookup (try #5) · 1788ea6e
      Jeff Layton 提交于
      commit d953126a changed how nfs_atomic_lookup handles an -EISDIR return
      from an OPEN call. Prior to that patch, that caused the client to fall
      back to doing a normal lookup. When that patch went in, the code began
      returning that error to userspace. The d_revalidate codepath however
      never had the corresponding change, so it was still possible to end up
      with a NULL ctx->state pointer after that.
      
      That patch caused a regression. When we attempt to open a directory that
      does not have a cached dentry, that open now errors out with EISDIR. If
      you attempt the same open with a cached dentry, it will succeed.
      
      Fix this by reverting the change in nfs_atomic_lookup and allowing
      attempts to open directories to fall back to a normal lookup
      
      Also, add a NFSv4-specific f_ops->open routine that just returns
      -ENOTDIR. This should never be called if things are working properly,
      but if it ever is, then the dprintk may help in debugging.
      
      To facilitate this, a new file_operations field is also added to the
      nfs_rpc_ops struct.
      
      Cc: stable@kernel.org
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1788ea6e
  10. 20 10月, 2011 2 次提交
  11. 19 10月, 2011 1 次提交
  12. 05 8月, 2011 1 次提交
  13. 01 8月, 2011 4 次提交
  14. 13 7月, 2011 6 次提交
  15. 15 6月, 2011 1 次提交
  16. 30 5月, 2011 2 次提交
  17. 12 5月, 2011 1 次提交
  18. 28 4月, 2011 1 次提交
    • T
      NFSv4: Ensure we request the ordinary fileid when doing readdirplus · 28331a46
      Trond Myklebust 提交于
      When readdir() returns a directory entry for the root of a mounted
      filesystem, Linux follows the old convention of returning the inode
      number of the covered directory (despite newer versions of POSIX declaring
      that this is a bug).
      To ensure this continues to work, the NFSv4 readdir implementation requests
      the 'mounted-on-fileid' from the server.
      
      However, readdirplus also needs to instantiate an inode for this entry, and
      for that, we also need to request the real fileid as per this patch.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      28331a46
  19. 25 3月, 2011 4 次提交
  20. 24 3月, 2011 2 次提交
  21. 15 3月, 2011 1 次提交
  22. 12 3月, 2011 1 次提交