1. 20 3月, 2012 1 次提交
  2. 15 2月, 2012 1 次提交
  3. 01 2月, 2012 2 次提交
  4. 07 12月, 2011 1 次提交
  5. 02 12月, 2011 1 次提交
  6. 18 7月, 2011 1 次提交
  7. 08 7月, 2011 1 次提交
  8. 15 6月, 2011 1 次提交
  9. 27 3月, 2011 1 次提交
    • O
      NFS: Ensure that rpc_release_resources_task() can be called twice. · a271c5a0
      OGAWA Hirofumi 提交于
      BUG: atomic_dec_and_test(): -1: atomic counter underflow at:
      Pid: 2827, comm: mount.nfs Not tainted 2.6.38 #1
      Call Trace:
       [<ffffffffa02223a0>] ? put_rpccred+0x44/0x14e [sunrpc]
       [<ffffffffa021bbe9>] ? rpc_ping+0x4e/0x58 [sunrpc]
       [<ffffffffa021c4a5>] ? rpc_create+0x481/0x4fc [sunrpc]
       [<ffffffffa022298a>] ? rpcauth_lookup_credcache+0xab/0x22d [sunrpc]
       [<ffffffffa028be8c>] ? nfs_create_rpc_client+0xa6/0xeb [nfs]
       [<ffffffffa028c660>] ? nfs4_set_client+0xc2/0x1f9 [nfs]
       [<ffffffffa028cd3c>] ? nfs4_create_server+0xf2/0x2a6 [nfs]
       [<ffffffffa0295d07>] ? nfs4_remote_mount+0x4e/0x14a [nfs]
       [<ffffffff810dd570>] ? vfs_kern_mount+0x6e/0x133
       [<ffffffffa029605a>] ? nfs_do_root_mount+0x76/0x95 [nfs]
       [<ffffffffa029643d>] ? nfs4_try_mount+0x56/0xaf [nfs]
       [<ffffffffa0297434>] ? nfs_get_sb+0x435/0x73c [nfs]
       [<ffffffff810dd59b>] ? vfs_kern_mount+0x99/0x133
       [<ffffffff810dd693>] ? do_kern_mount+0x48/0xd8
       [<ffffffff810f5b75>] ? do_mount+0x6da/0x741
       [<ffffffff810f5c5f>] ? sys_mount+0x83/0xc0
       [<ffffffff8100293b>] ? system_call_fastpath+0x16/0x1b
      
      Well, so, I think this is real bug of nfs codes somewhere. With some
      review, the code
      
      rpc_call_sync()
          rpc_run_task
              rpc_execute()
                  __rpc_execute()
                      rpc_release_task()
                          rpc_release_resources_task()
                              put_rpccred()                <= release cred
          rpc_put_task
              rpc_do_put_task()
                  rpc_release_resources_task()
                      put_rpccred()                        <= release cred again
      
      seems to be release cred unintendedly.
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a271c5a0
  10. 18 3月, 2011 1 次提交
  11. 12 3月, 2011 2 次提交
  12. 11 3月, 2011 1 次提交
    • T
      SUNRPC: Close a race in __rpc_wait_for_completion_task() · bf294b41
      Trond Myklebust 提交于
      Although they run as rpciod background tasks, under normal operation
      (i.e. no SIGKILL), functions like nfs_sillyrename(), nfs4_proc_unlck()
      and nfs4_do_close() want to be fully synchronous. This means that when we
      exit, we want all references to the rpc_task to be gone, and we want
      any dentry references etc. held by that task to be released.
      
      For this reason these functions call __rpc_wait_for_completion_task(),
      followed by rpc_put_task() in the expectation that the latter will be
      releasing the last reference to the rpc_task, and thus ensuring that the
      callback_ops->rpc_release() has been called synchronously.
      
      This patch fixes a race which exists due to the fact that
      rpciod calls rpc_complete_task() (in order to wake up the callers of
      __rpc_wait_for_completion_task()) and then subsequently calls
      rpc_put_task() without ensuring that these two steps are done atomically.
      
      In order to avoid adding new spin locks, the patch uses the existing
      waitqueue spin lock to order the rpc_task reference count releases between
      the waiting process and rpciod.
      The common case where nobody is waiting for completion is optimised for by
      checking if the RPC_TASK_ASYNC flag is cleared and/or if the rpc_task
      reference count is 1: in those cases we drop trying to grab the spin lock,
      and immediately free up the rpc_task.
      
      Those few processes that need to put the rpc_task from inside an
      asynchronous context and that do not care about ordering are given a new
      helper: rpc_put_task_async().
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bf294b41
  13. 25 1月, 2011 1 次提交
  14. 24 9月, 2010 1 次提交
  15. 22 9月, 2010 1 次提交
  16. 04 8月, 2010 4 次提交
  17. 15 5月, 2010 3 次提交
  18. 16 12月, 2009 2 次提交
  19. 11 9月, 2009 1 次提交
  20. 13 7月, 2009 1 次提交
  21. 18 6月, 2009 1 次提交
  22. 11 3月, 2009 1 次提交
    • T
      SUNRPC: Tighten up the task locking rules in __rpc_execute() · eb9b55ab
      Trond Myklebust 提交于
      We should probably not be testing any flags after we've cleared the
      RPC_TASK_RUNNING flag, since rpc_make_runnable() is then free to assign the
      rpc_task to another workqueue, which may then destroy it.
      
      We can fix any races with rpc_make_runnable() by ensuring that we only
      clear the RPC_TASK_RUNNING flag while holding the rpc_wait_queue->lock that
      the task is supposed to be sleeping on (and then checking whether or not
      the task really is sleeping).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      eb9b55ab
  23. 16 7月, 2008 1 次提交
  24. 10 7月, 2008 1 次提交
  25. 15 3月, 2008 2 次提交
  26. 29 2月, 2008 5 次提交
  27. 26 2月, 2008 1 次提交
    • T
      SUNRPC: Run rpc timeout functions as callbacks instead of in softirqs · 5d00837b
      Trond Myklebust 提交于
      An audit of the current RPC timeout functions shows that they don't really
      ever need to run in the softirq context. As long as the softirq is
      able to signal that the wakeup is due to a timeout (which it can do by
      setting task->tk_status to -ETIMEDOUT) then the callback functions can just
      run as standard task->tk_callback functions (in the rpciod/process
      context).
      
      The only possible border-line case would be xprt_timer() for the case of
      UDP, when the callback is used to reduce the size of the transport
      congestion window. In testing, however, the effect of moving that update
      to a callback would appear to be minor.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      5d00837b