1. 31 7月, 2012 2 次提交
    • J
      nfs: skip commit in releasepage if we're freeing memory for fs-related reasons · 5cf02d09
      Jeff Layton 提交于
      We've had some reports of a deadlock where rpciod ends up with a stack
      trace like this:
      
          PID: 2507   TASK: ffff88103691ab40  CPU: 14  COMMAND: "rpciod/14"
           #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
           #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
           #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
           #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
           #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
           #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
           #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
           #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
           #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
           #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
          #10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
          #11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
          #12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
          #13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
          #14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
          #15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
          #16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
          #17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
          #18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
          #19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
          #20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
          #21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
          #22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
          #23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
          #24 [ffff8810343bfee8] kthread at ffffffff8108dd96
          #25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca
      
      rpciod is trying to allocate memory for a new socket to talk to the
      server. The VM ends up calling ->releasepage to get more memory, and it
      tries to do a blocking commit. That commit can't succeed however without
      a connected socket, so we deadlock.
      
      Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
      socket allocation, and having nfs_release_page check for that flag when
      deciding whether to do a commit call. Also, set PF_FSTRANS
      unconditionally in rpc_async_schedule since that function can also do
      allocations sometimes.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      5cf02d09
    • J
      sunrpc: clarify comments on rpc_make_runnable · 506026c3
      Jeff Layton 提交于
      rpc_make_runnable is not generally called with the queue lock held, unless
      it's waking up a task that has been sitting on a waitqueue. This is safe
      when the task has not entered the FSM yet, but the comments don't really
      spell this out.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      506026c3
  2. 20 3月, 2012 1 次提交
  3. 15 2月, 2012 1 次提交
  4. 01 2月, 2012 2 次提交
  5. 07 12月, 2011 1 次提交
  6. 02 12月, 2011 1 次提交
  7. 18 7月, 2011 1 次提交
  8. 08 7月, 2011 1 次提交
  9. 15 6月, 2011 1 次提交
  10. 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
  11. 18 3月, 2011 1 次提交
  12. 12 3月, 2011 2 次提交
  13. 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
  14. 25 1月, 2011 1 次提交
  15. 24 9月, 2010 1 次提交
  16. 22 9月, 2010 1 次提交
  17. 04 8月, 2010 4 次提交
  18. 15 5月, 2010 3 次提交
  19. 16 12月, 2009 2 次提交
  20. 11 9月, 2009 1 次提交
  21. 13 7月, 2009 1 次提交
  22. 18 6月, 2009 1 次提交
  23. 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
  24. 16 7月, 2008 1 次提交
  25. 10 7月, 2008 1 次提交
  26. 15 3月, 2008 2 次提交
  27. 29 2月, 2008 4 次提交