1. 10 Dec, 2012 8 commits
  2. 04 Dec, 2012 6 commits
  3. 03 Dec, 2012 10 commits
  4. 28 Nov, 2012 13 commits
  5. 27 Nov, 2012 1 commit
  6. 26 Nov, 2012 2 commits
    • J. Bruce Fields's avatar
      nfsd4: downgrade some fs/nfsd/nfs4state.c BUG's · 063b0fb9
      J. Bruce Fields authored
      Linus has pointed out that indiscriminate use of BUG's can make it
      harder to diagnose bugs because they can bring a machine down, often
      before we manage to get any useful debugging information to the logs.
      (Consider, for example, a BUG() that fires in a workqueue, or while
      holding a spinlock).
      
      Most of these BUG's won't do much more than kill an nfsd thread, but it
      would still probably be safer to get out the warning without dying.
      
      There's still more of this to do in nfsd/.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      063b0fb9
    • J. Bruce Fields's avatar
      nfsd4: delay filling in write iovec array till after xdr decoding · ffe1137b
      J. Bruce Fields authored
      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: default avatarJ. Bruce Fields <bfields@redhat.com>
      ffe1137b