1. 03 3月, 2012 1 次提交
    • C
      NFS: Clean up debugging in decode_pathname() · 02a2976c
      Chuck Lever 提交于
      I noticed recently that decode_attr_fs_locations() is not generating
      very pretty debugging output.  The pathname components each appear on
      a separate line of output, though that does not appear to be the
      intended display behavior.  The preferred way to generate continued
      lines of output on the console is to use pr_cont().
      
      Note that incoming pathname4 components contain a string that is not
      necessarily NUL-terminated.  I did actually see some trailing garbage
      on the console.  In addition to correcting the line continuation
      problem, add a string precision format specifier to ensure that each
      component string is displayed properly, and that vsnprintf() does
      not Oops.
      
      Someone pointed out that allowing incoming network data to possibly
      generate a console line of unbounded length may not be such a good
      idea.  Since this output will rarely be enabled, and there is a hard
      upper bound (NFS4_PATHNAME_MAXCOMPONENTS) in our implementation, this
      is probably not a major concern.
      
      It might be useful to additionally sanity-check the length of each
      incoming component, however.  RFC 3530bis15 does not suggest a maximum
      number of UTF-8 characters per component for either the pathname4 or
      component4 types.  However, we could invent one that is appropriate
      for our implementation.
      
      Another possibility is to scrap all of this and print these pathnames
      in upper layers after a reasonable amount of sanity checking in the
      XDR layer.  This would give us an opportunity to allocate a full
      buffer so that the whole pathname would be output via a single
      dprintk.
      
      Introduced by commit 7aaa0b3b: "NFSv4: convert fs-locations-components
      to conform to RFC3530," (June 9, 2006).
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      02a2976c
  2. 02 3月, 2012 2 次提交
  3. 07 2月, 2012 3 次提交
  4. 01 2月, 2012 2 次提交
  5. 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
  6. 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
  7. 31 10月, 2011 1 次提交
  8. 01 8月, 2011 4 次提交
  9. 13 7月, 2011 4 次提交
  10. 12 7月, 2011 1 次提交
  11. 21 6月, 2011 1 次提交
  12. 17 6月, 2011 1 次提交
  13. 15 6月, 2011 1 次提交
  14. 30 5月, 2011 3 次提交
  15. 28 4月, 2011 2 次提交
    • B
      NFS: Return meaningful status from decode_secinfo() · 613e901e
      Bryan Schumaker 提交于
      When compiling, I was getting this warning:
      fs/nfs/nfs4xdr.c: In function ‘decode_secinfo’:
      fs/nfs/nfs4xdr.c:4839:6: warning: variable ‘status’ set but not used
      [-Wunused-but-set-variable]
      
      We were unconditionally returning 0 as long as there wasn't an error
      coming out of xdr_inline_decode().  We probably want to check the error
      status coming out of decode_op_hdr() and decode_secinfo_gss(), rather
      than assuming that everything is OK all the time.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      613e901e
    • 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
  16. 14 4月, 2011 1 次提交
    • B
      NFS: Use correct variable for page bounds checking · c3dfc280
      Bryan Schumaker 提交于
      While decoding a secinfo reply, I store the list of supported sec
      flavors on a page accessible through res->flavors.  Before reading
      each new flavor, I do some math to determine if there is enough
      space left on this page, and I break out of my read look if there
      isn't.  In order to perform this check correctly, I need to use the
      address of res->flavors, rather than the address of res.
      
      When this loop was broken early I lied to the caller and told them
      that the entire list had been decoded.  This could lead to problems
      if the caller tries to use any the garbage data claiming to be a
      valid sec flavor.  I fixed this by using res->flavors->num_flavors
      as a counter, incrementing it every time a sec flavor is
      successfully decoded.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c3dfc280
  17. 25 3月, 2011 3 次提交
  18. 24 3月, 2011 2 次提交
  19. 12 3月, 2011 4 次提交
  20. 11 3月, 2011 1 次提交
  21. 29 1月, 2011 1 次提交
    • C
      NFS: NFSv4 readdir loses entries · d1205f87
      Chuck Lever 提交于
      On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
      NFSv4 mounts of OpenSolaris with something like:
      
      > ./test6: readdir
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
      > basic tests failed
      > Tests failed, leaving /mnt/klimt mounted
      > [cel@matisse cthon04]$
      
      I narrowed the problem down to nfs4_decode_dirent() reporting that the
      decode buffer had overflowed while decoding the entries for those
      missing files.
      
      verify_attr_len() assumes both it's pointer arguments reside on the
      same page.  When these arguments point to locations on two different
      pages, verify_attr_len() can report false errors.  This can happen now
      that a large NFSv4 readdir result can span pages.
      
      We have reasonably good checking in nfs4_decode_dirent() anyway, so
      it should be safe to simply remove the extra checking.
      
      At a guess, this was introduced by commit 6650239a, "NFS: Don't use
      vm_map_ram() in readdir".
      
      Cc: stable@kernel.org [2.6.37]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d1205f87