1. 15 12月, 2009 2 次提交
  2. 16 9月, 2009 8 次提交
  3. 14 9月, 2009 1 次提交
  4. 21 8月, 2009 1 次提交
  5. 19 6月, 2009 2 次提交
  6. 04 5月, 2009 1 次提交
  7. 02 5月, 2009 4 次提交
  8. 30 4月, 2009 5 次提交
  9. 19 3月, 2009 6 次提交
  10. 08 1月, 2009 1 次提交
  11. 24 12月, 2008 2 次提交
  12. 30 9月, 2008 3 次提交
  13. 10 7月, 2008 1 次提交
    • O
      rpc: bring back cl_chatty · b6b6152c
      Olga Kornievskaia 提交于
      The cl_chatty flag alows us to control whether a given rpc client leaves
      
      	"server X not responding, timed out"
      
      messages in the syslog.  Such messages make sense for ordinary nfs
      clients (where an unresponsive server means applications on the
      mountpoint are probably hanging), but not for the callback client (which
      can fail more commonly, with the only result just of disabling some
      optimizations).
      
      Previously cl_chatty was removed, do to lack of users; reinstate it, and
      use it for the nfsd's callback client.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b6b6152c
  14. 19 5月, 2008 1 次提交
  15. 30 4月, 2008 1 次提交
  16. 24 4月, 2008 1 次提交
    • O
      nfsd: use static memory for callback program and stats · ff7d9756
      Olga Kornievskaia 提交于
      There's no need to dynamically allocate this memory, and doing so may
      create the possibility of races on shutdown of the rpc client.  (We've
      witnessed it only after adding rpcsec_gss support to the server, after
      which the rpc code can send destroys calls that expect to still be able
      to access the rpc_stats structure after it has been destroyed.)
      
      Such races are in theory possible if the module containing this "static"
      memory is removed very quickly after an rpc client is destroyed, but
      we haven't seen that happen.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      ff7d9756