1. 29 4月, 2020 1 次提交
    • N
      SUNRPC: defer slow parts of rpc_free_client() to a workqueue. · 7c4310ff
      NeilBrown 提交于
      The rpciod workqueue is on the write-out path for freeing dirty memory,
      so it is important that it never block waiting for memory to be
      allocated - this can lead to a deadlock.
      
      rpc_execute() - which is often called by an rpciod work item - calls
      rcp_task_release_client() which can lead to rpc_free_client().
      
      rpc_free_client() makes two calls which could potentially block wating
      for memory allocation.
      
      rpc_clnt_debugfs_unregister() calls into debugfs and will block while
      any of the debugfs files are being accessed.  In particular it can block
      while any of the 'open' methods are being called and all of these use
      malloc for one thing or another.  So this can deadlock if the memory
      allocation waits for NFS to complete some writes via rpciod.
      
      rpc_clnt_remove_pipedir() can take the inode_lock() and while it isn't
      obvious that memory allocations can happen while the lock it held, it is
      safer to assume they might and to not let rpciod call
      rpc_clnt_remove_pipedir().
      
      So this patch moves these two calls (together with the final kfree() and
      rpciod_down()) into a work-item to be run from the system work-queue.
      rpciod can continue its important work, and the final stages of the free
      can happen whenever they happen.
      
      I have seen this deadlock on a 4.12 based kernel where debugfs used
      synchronize_srcu() when removing objects.  synchronize_srcu() requires a
      workqueue and there were no free workther threads and none could be
      allocated.  While debugsfs no longer uses SRCU, I believe the deadlock
      is still possible.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      7c4310ff
  2. 22 4月, 2020 1 次提交
  3. 17 3月, 2020 1 次提交
  4. 16 3月, 2020 2 次提交
  5. 15 1月, 2020 1 次提交
  6. 04 11月, 2019 1 次提交
    • T
      NFSv4.1: Don't rebind to the same source port when reconnecting to the server · e6237b6f
      Trond Myklebust 提交于
      NFSv2, v3 and NFSv4 servers often have duplicate replay caches that look
      at the source port when deciding whether or not an RPC call is a replay
      of a previous call. This requires clients to perform strange TCP gymnastics
      in order to ensure that when they reconnect to the server, they bind
      to the same source port.
      
      NFSv4.1 and NFSv4.2 have sessions that provide proper replay semantics,
      that do not look at the source port of the connection. This patch therefore
      ensures they can ignore the rebind requirement.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      e6237b6f
  7. 24 10月, 2019 1 次提交
  8. 21 9月, 2019 1 次提交
  9. 18 9月, 2019 2 次提交
  10. 27 8月, 2019 3 次提交
  11. 19 7月, 2019 1 次提交
  12. 18 7月, 2019 1 次提交
  13. 13 7月, 2019 1 次提交
  14. 07 7月, 2019 3 次提交
  15. 22 6月, 2019 2 次提交
  16. 31 5月, 2019 2 次提交
  17. 21 5月, 2019 1 次提交
  18. 10 5月, 2019 1 次提交
  19. 27 4月, 2019 1 次提交
  20. 26 4月, 2019 8 次提交
  21. 18 4月, 2019 1 次提交
  22. 12 4月, 2019 1 次提交
  23. 23 3月, 2019 1 次提交
  24. 16 3月, 2019 2 次提交