1. 28 Nov, 2012 2 commits
    • Stanislav Kinsbursky's avatar
      nfsd4: remove state lock from nfs4_state_shutdown · ec28e02c
      Stanislav Kinsbursky authored
      Protection of __nfs4_state_shutdown() with nfs4_lock_state() looks redundant.
      
      This function is called by the last NFSd thread on it's exit and state lock
      protects actually two functions (del_recall_lru is protected by recall_lock):
      1) nfsd4_client_tracking_exit
      2) __nfs4_state_shutdown_net
      
      "nfsd4_client_tracking_exit" doesn't require state lock protection, because it's
      state can be modified only by tracker callbacks.
      Here a re they:
      1) create: is called only from nfsd4_proc_compound.
      2) remove: is called from either nfsd4_proc_compound or nfs4_laundromat.
      3) check: is called only from nfsd4_proc_compound.
      4) grace_done; called only from nfs4_laundromat.
      
      nfsd4_proc_compound is called onll by NFSd kthread, which is exiting right
      now.
      nfs4_laundromat is called by laundry_wq. But laundromat_work was canceled
      already.
      
      "__nfs4_state_shutdown_net" also doesn't require state lock protection,
      because all NFSd kthreads are dead, and no race can happen with NFSd start,
      because "nfsd_up" flag is still set.
      Moreover, all Nfsd shutdown is protected with global nfsd_mutex.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      ec28e02c
    • J. Bruce Fields's avatar
      nfsd4: remove state lock from nfsd4_load_reboot_recovery_data · dba88ba5
      J. Bruce Fields authored
      That function is only called under nfsd_mutex: we know that because the
      only caller is nfsd_svc, via
      
              nfsd_svc
                nfsd_startup
                  nfs4_state_start
                    nfsd4_client_tracking_init
                      client_tracking_ops->init == nfsd4_load_reboot_recovery_data
      
      The shared state accessed here includes:
      
              - user_recovery_dirname: used here, modified only by
                nfs4_reset_recoverydir, which can be verified to only be
                called under nfsd_mutex.
              - filesystem state, protected by i_mutex (handwaving slightly
      	  here)
              - rec_file, reclaim_str_hashtbl, reclaim_str_hashtbl_size: other
                than here, used only from code called from nfsd or laundromat
                threads, both of which should be started only after this runs
                (see nfsd_svc) and stopped before this could run again (see
                nfsd_shutdown, called from nfsd_last_thread).
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      dba88ba5
  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 11 commits
  7. 10 Nov, 2012 1 commit