1. 23 Mar, 2011 3 commits
    • Steven Rostedt's avatar
      ftrace: Fix memory leak with function graph and cpu hotplug · 1883e22e
      Steven Rostedt authored
      commit 868baf07 upstream.
      
      When the fuction graph tracer starts, it needs to make a special
      stack for each task to save the real return values of the tasks.
      All running tasks have this stack created, as well as any new
      tasks.
      
      On CPU hot plug, the new idle task will allocate a stack as well
      when init_idle() is called. The problem is that cpu hotplug does
      not create a new idle_task. Instead it uses the idle task that
      existed when the cpu went down.
      
      ftrace_graph_init_task() will add a new ret_stack to the task
      that is given to it. Because a clone will make the task
      have a stack of its parent it does not check if the task's
      ret_stack is already NULL or not. When the CPU hotplug code
      starts a CPU up again, it will allocate a new stack even
      though one already existed for it.
      
      The solution is to treat the idle_task specially. In fact, the
      function_graph code already does, just not at init_idle().
      Instead of using the ftrace_graph_init_task() for the idle task,
      which that function expects the task to be a clone, have a
      separate ftrace_graph_init_idle_task(). Also, we will create a
      per_cpu ret_stack that is used by the idle task. When we call
      ftrace_graph_init_idle_task() it will check if the idle task's
      ret_stack is NULL, if it is, then it will assign it the per_cpu
      ret_stack.
      Reported-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Suggested-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1883e22e
    • Trond Myklebust's avatar
      VFS: Fix the nfs sillyrename regression in kernel 2.6.38 · 2c048b5d
      Trond Myklebust authored
      commit c83ce989 upstream.
      
      The new vfs locking scheme introduced in 2.6.38 breaks NFS sillyrename
      because the latter relies on being able to determine the parent
      directory of the dentry in the ->iput() callback in order to send the
      appropriate unlink rpc call.
      
      Looking at the code that cares about races with dput(), there doesn't
      seem to be anything that specifically uses d_parent as a test for
      whether or not there is a race:
        - __d_lookup_rcu(), __d_lookup() all test for d_hashed() after d_parent
        - shrink_dcache_for_umount() is safe since nothing else can rearrange
          the dentries in that super block.
        - have_submount(), select_parent() and d_genocide() can test for a
          deletion if we set the DCACHE_DISCONNECTED flag when the dentry
          is removed from the parent's d_subdirs list.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2c048b5d
    • Linus Torvalds's avatar
      dcache.c: create helper function for duplicated functionality · c4e8d54f
      Linus Torvalds authored
      commit c826cb7d upstream.
      
      This creates a helper function for he "try to ascend into the parent
      directory" case, which was written out in triplicate before.  With all
      the locking and subtle sequence number stuff, we really don't want to
      duplicate that kind of code.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c4e8d54f
  2. 15 Mar, 2011 1 commit
  3. 14 Mar, 2011 36 commits