1. 24 1月, 2013 1 次提交
  2. 18 12月, 2012 1 次提交
  3. 26 11月, 2012 2 次提交
    • J
      nfsd4: delay filling in write iovec array till after xdr decoding · ffe1137b
      J. Bruce Fields 提交于
      Our server rejects compounds containing more than one write operation.
      It's unclear whether this is really permitted by the spec; with 4.0,
      it's possibly OK, with 4.1 (which has clearer limits on compound
      parameters), it's probably not OK.  No client that we're aware of has
      ever done this, but in theory it could be useful.
      
      The source of the limitation: we need an array of iovecs to pass to the
      write operation.  In the worst case that array of iovecs could have
      hundreds of elements (the maximum rwsize divided by the page size), so
      it's too big to put on the stack, or in each compound op.  So we instead
      keep a single such array in the compound argument.
      
      We fill in that array at the time we decode the xdr operation.
      
      But we decode every op in the compound before executing any of them.  So
      once we've used that array we can't decode another write.
      
      If we instead delay filling in that array till the time we actually
      perform the write, we can reuse it.
      
      Another option might be to switch to decoding compound ops one at a
      time.  I considered doing that, but it has a number of other side
      effects, and I'd rather fix just this one problem for now.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ffe1137b
    • J
      nfsd4: move more write parameters into xdr argument · 70cc7f75
      J. Bruce Fields 提交于
      In preparation for moving some of this elsewhere.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      70cc7f75
  4. 15 11月, 2012 1 次提交
  5. 08 11月, 2012 1 次提交
  6. 01 6月, 2012 1 次提交
  7. 21 3月, 2012 1 次提交
    • C
      NFSD: Fix nfs4_verifier memory alignment · ab4684d1
      Chuck Lever 提交于
      Clean up due to code review.
      
      The nfs4_verifier's data field is not guaranteed to be u32-aligned.
      Casting an array of chars to a u32 * is considered generally
      hazardous.
      
      We can fix most of this by using a __be32 array to generate the
      verifier's contents and then byte-copying it into the verifier field.
      
      However, there is one spot where there is a backwards compatibility
      constraint: the do_nfsd_create() call expects a verifier which is
      32-bit aligned.  Fix this spot by forcing the alignment of the create
      verifier in the nfsd4_open args structure.
      
      Also, sizeof(nfs4_verifer) is the size of the in-core verifier data
      structure, but NFS4_VERIFIER_SIZE is the number of octets in an XDR'd
      verifier.  The two are not interchangeable, even if they happen to
      have the same value.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ab4684d1
  8. 18 2月, 2012 3 次提交
  9. 16 2月, 2012 3 次提交
  10. 15 2月, 2012 1 次提交
    • J
      nfsd4: rearrange struct nfsd4_slot · 73e79482
      J. Bruce Fields 提交于
      Combine two booleans into a single flag field, move the smaller fields
      to the end.
      
      (In practice this doesn't make the struct any smaller.  But we'll be
      adding another flag here soon.)
      
      Remove some debugging code that doesn't look useful, while we're in the
      neighborhood.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      73e79482
  11. 24 10月, 2011 1 次提交
  12. 18 10月, 2011 4 次提交
  13. 12 10月, 2011 1 次提交
  14. 27 9月, 2011 1 次提交
  15. 16 9月, 2011 1 次提交
    • M
      nfsd41: try to check reply size before operation · 58e7b33a
      Mi Jinlong 提交于
      For checking the size of reply before calling a operation,
      we need try to get maxsize of the operation's reply.
      
      v3: using new method as Bruce said,
      
       "we could handle operations in two different ways:
      
      	- For operations that actually change something (write, rename,
      	  open, close, ...), do it the way we're doing it now: be
      	  very careful to estimate the size of the response before even
      	  processing the operation.
      	- For operations that don't change anything (read, getattr, ...)
      	  just go ahead and do the operation.  If you realize after the
      	  fact that the response is too large, then return the error at
      	  that point.
      
        So we'd add another flag to op_flags: say, OP_MODIFIES_SOMETHING.  And for
        operations with OP_MODIFIES_SOMETHING set, we'd do the first thing.  For
        operations without it set, we'd do the second."
      Signed-off-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
      [bfields@redhat.com: crash, don't attempt to handle, undefined op_rsize_bop]
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      58e7b33a
  16. 07 9月, 2011 1 次提交
  17. 01 9月, 2011 3 次提交
  18. 28 8月, 2011 1 次提交
  19. 18 7月, 2011 2 次提交
  20. 16 7月, 2011 2 次提交
  21. 12 1月, 2011 2 次提交
  22. 18 12月, 2010 1 次提交
  23. 09 12月, 2010 1 次提交
    • N
      nfsd: Fix possible BUG_ON firing in set_change_info · c1ac3ffc
      Neil Brown 提交于
      If vfs_getattr in fill_post_wcc returns an error, we don't
      set fh_post_change.
      For NFSv4, this can result in set_change_info triggering a BUG_ON.
      i.e. fh_post_saved being zero isn't really a bug.
      
      So:
       - instead of BUGging when fh_post_saved is zero, just clear ->atomic.
       - if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway.
         This will be used i seg_change_info, but not overly trusted.
       - While we are there, remove the pointless 'if' statements in set_change_info.
         There is no harm setting all the values.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c1ac3ffc
  24. 14 5月, 2010 1 次提交
  25. 20 4月, 2010 1 次提交
  26. 16 12月, 2009 1 次提交
  27. 15 12月, 2009 1 次提交