1. 28 Nov, 2012 10 commits
  2. 27 Nov, 2012 1 commit
  3. 26 Nov, 2012 7 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
    • J. Bruce Fields's avatar
      nfsd4: move more write parameters into xdr argument · 70cc7f75
      J. Bruce Fields authored
      In preparation for moving some of this elsewhere.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      70cc7f75
    • J. Bruce Fields's avatar
      nfsd4: reorganize write decoding · 5a80a54d
      J. Bruce Fields authored
      In preparation for moving some of it elsewhere.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      5a80a54d
    • J. Bruce Fields's avatar
      nfsd4: simplify reading of opnum · 8a61b18c
      J. Bruce Fields authored
      The comment here is totally bogus:
      	- OP_WRITE + 1 is RELEASE_LOCKOWNER.  Maybe there was some older
      	  version of the spec in which that served as a sort of
      	  OP_ILLEGAL?  No idea, but it's clearly wrong now.
      	- In any case, I can't see that the spec says anything about
      	  what to do if the client sends us less ops than promised.
      	  It's clearly nutty client behavior, and we should do
      	  whatever's easiest: returning an xdr error (even though it
      	  won't be consistent with the error on the last op returned)
      	  seems fine to me.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      8a61b18c
    • J. Bruce Fields's avatar
      447bfcc9
    • J. Bruce Fields's avatar
      nfsd: fix v4 reply caching · 57d276d7
      J. Bruce Fields authored
      Very embarassing: 1091006c "nfsd: turn
      on reply cache for NFSv4" missed a line, effectively leaving the reply
      cache off in the v4 case.  I thought I'd tested that, but I guess not.
      
      This time, wrote a pynfs test to confirm it works.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      57d276d7
  4. 15 Nov, 2012 16 commits
  5. 14 Nov, 2012 2 commits
  6. 12 Nov, 2012 4 commits
    • Jeff Layton's avatar
      nfsd: release the legacy reclaimable clients list in grace_done · 7e4f015d
      Jeff Layton authored
      The current code holds on to this list until nfsd is shut down, but it's
      never touched once the grace period ends. Release that memory back into
      the wild when the grace period ends.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7e4f015d
    • Jeff Layton's avatar
      nfsd: get rid of cl_recdir field · 2216d449
      Jeff Layton authored
      Remove the cl_recdir field from the nfs4_client struct. Instead, just
      compute it on the fly when and if it's needed, which is now only when
      the legacy client tracking code is in effect.
      
      The error handling in the legacy client tracker is also changed to
      handle the case where md5 is unavailable. In that case, we'll warn
      the admin with a KERN_ERR message and disable the client tracking.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2216d449
    • Jeff Layton's avatar
      nfsd: move the confirmed and unconfirmed hlists to a rbtree · ac55fdc4
      Jeff Layton authored
      The current code requires that we md5 hash the name in order to store
      the client in the confirmed and unconfirmed trees. Change it instead
      to store the clients in a pair of rbtrees, and simply compare the
      cl_names directly instead of hashing them. This also necessitates that
      we add a new flag to the clp->cl_flags field to indicate which tree
      the client is currently in.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      ac55fdc4
    • Jeff Layton's avatar
      nfsd: don't search for client by hash on legacy reboot recovery gracedone · 0ce0c2b5
      Jeff Layton authored
      When nfsd starts, the legacy reboot recovery code creates a tracking
      struct for each directory in the v4recoverydir. When the grace period
      ends, it basically does a "readdir" on the directory again, and matches
      each dentry in there to an existing client id to see if it should be
      removed or not. If the matching client doesn't exist, or hasn't
      reclaimed its state then it will remove that dentry.
      
      This is pretty inefficient since it involves doing a lot of hash-bucket
      searching. It also means that we have to keep relying on being able to
      search for a nfs4_client by md5 hashed cl_recdir name.
      
      Instead, add a pointer to the nfs4_client that indicates the association
      between the nfs4_client_reclaim and nfs4_client. When a reclaim operation
      comes in, we set the pointer to make that association. On gracedone, the
      legacy client tracker will keep the recdir around iff:
      
      1/ there is a reclaim record for the directory
      
      ...and...
      
      2/ there's an association between the reclaim record and a client record
      -- that is, a create or check operation was performed on the client that
      matches that directory.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      0ce0c2b5