1. 26 Sep, 2014 1 commit
    • Zefan Li's avatar
      Revert "cgroup: remove redundant variable in cgroup_mount()" · e756c7b6
      Zefan Li authored
      This reverts commit 0c7bf3e8.
      
      If there are child cgroups in the cgroupfs and then we umount it,
      the superblock will be destroyed but the cgroup_root will be kept
      around. When we mount it again, cgroup_mount() will find this
      cgroup_root and allocate a new sb for it.
      
      So with this commit we will be trapped in a dead loop in the case
      described above, because kernfs_pin_sb() keeps returning NULL.
      
      Currently I don't see how we can avoid using both pinned_sb and
      new_sb, so just revert it.
      
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Reported-by: default avatarAndrey Wagin <avagin@gmail.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      e756c7b6
  2. 20 Sep, 2014 2 commits
  3. 19 Sep, 2014 3 commits
    • Zefan Li's avatar
      cgroup: remove CGRP_RELEASABLE flag · a25eb52e
      Zefan Li authored
      We call put_css_set() after setting CGRP_RELEASABLE flag in
      cgroup_task_migrate(), but in other places we call it without setting
      the flag. I don't see the necessity of this flag.
      
      Moreover once the flag is set, it will never be cleared, unless writing
      to the notify_on_release control file, so it can be quite confusing
      if we look at the output of debug.releasable.
      
        # mount -t cgroup -o debug xxx /cgroup
        # mkdir /cgroup/child
        # cat /cgroup/child/debug.releasable
        0   <-- shows 0 though the cgroup is empty
        # echo $$ > /cgroup/child/tasks
        # cat /cgroup/child/debug.releasable
        0
        # echo $$ > /cgroup/tasks && echo $$ > /cgroup/child/tasks
        # cat /proc/child/debug.releasable
        1   <-- shows 1 though the cgroup is not empty
      
      This patch removes the flag, and now debug.releasable shows if the
      cgroup is empty or not.
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      a25eb52e
    • Zefan Li's avatar
      perf/cgroup: Remove perf_put_cgroup() · 4e2ba650
      Zefan Li authored
      Commit 5a17f543 ("cgroup: improve css_from_dir() into css_tryget_from_dir()")
      removed perf_tryget_cgroup(), so let's also remove perf_put_cgroup().
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      4e2ba650
    • Zefan Li's avatar
      cgroup: remove redundant check in cgroup_ino() · f29374b1
      Zefan Li authored
      After we implemented default unified hierarchy, cgrp->kn can never
      be NULL.
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      f29374b1
  4. 18 Sep, 2014 3 commits
  5. 17 Sep, 2014 4 commits
  6. 04 Sep, 2014 2 commits
    • Li Zefan's avatar
      cgroup: check cgroup liveliness before unbreaking kernfs · aa32362f
      Li Zefan authored
      When cgroup_kn_lock_live() is called through some kernfs operation and
      another thread is calling cgroup_rmdir(), we'll trigger the warning in
      cgroup_get().
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0()
      ...
      Call Trace:
       [<c16ee73d>] dump_stack+0x41/0x52
       [<c10468ef>] warn_slowpath_common+0x7f/0xa0
       [<c104692d>] warn_slowpath_null+0x1d/0x20
       [<c10bb999>] cgroup_get+0x89/0xa0
       [<c10bbe58>] cgroup_kn_lock_live+0x28/0x70
       [<c10be3c1>] __cgroup_procs_write.isra.26+0x51/0x230
       [<c10be5b2>] cgroup_tasks_write+0x12/0x20
       [<c10bb7b0>] cgroup_file_write+0x40/0x130
       [<c11aee71>] kernfs_fop_write+0xd1/0x160
       [<c1148e58>] vfs_write+0x98/0x1e0
       [<c114934d>] SyS_write+0x4d/0xa0
       [<c16f656b>] sysenter_do_call+0x12/0x12
      ---[ end trace 6f2e0c38c2108a74 ]---
      
      Fix this by calling css_tryget() instead of cgroup_get().
      
      v2:
      - move cgroup_tryget() right below cgroup_get() definition. (Tejun)
      
      Cc: <stable@vger.kernel.org> # 3.15+
      Reported-by: default avatarToralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      aa32362f
    • Li Zefan's avatar
      cgroup: delay the clearing of cgrp->kn->priv · a4189487
      Li Zefan authored
      Run these two scripts concurrently:
      
          for ((; ;))
          {
              mkdir /cgroup/sub
              rmdir /cgroup/sub
          }
      
          for ((; ;))
          {
              echo $$ > /cgroup/sub/cgroup.procs
              echo $$ > /cgroup/cgroup.procs
          }
      
      A kernel bug will be triggered:
      
      BUG: unable to handle kernel NULL pointer dereference at 00000038
      IP: [<c10bbd69>] cgroup_put+0x9/0x80
      ...
      Call Trace:
       [<c10bbe19>] cgroup_kn_unlock+0x39/0x50
       [<c10bbe91>] cgroup_kn_lock_live+0x61/0x70
       [<c10be3c1>] __cgroup_procs_write.isra.26+0x51/0x230
       [<c10be5b2>] cgroup_tasks_write+0x12/0x20
       [<c10bb7b0>] cgroup_file_write+0x40/0x130
       [<c11aee71>] kernfs_fop_write+0xd1/0x160
       [<c1148e58>] vfs_write+0x98/0x1e0
       [<c114934d>] SyS_write+0x4d/0xa0
       [<c16f656b>] sysenter_do_call+0x12/0x12
      
      We clear cgrp->kn->priv in the end of cgroup_rmdir(), but another
      concurrent thread can access kn->priv after the clearing.
      
      We should move the clearing to css_release_work_fn(). At that time
      no one is holding reference to the cgroup and no one can gain a new
      reference to access it.
      
      v2:
      - move RCU_INIT_POINTER() into the else block. (Tejun)
      - remove the cgroup_parent() check. (Tejun)
      - update the comment in css_tryget_online_from_dir().
      
      Cc: <stable@vger.kernel.org> # 3.15+
      Reported-by: default avatarToralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      a4189487
  7. 25 Aug, 2014 1 commit
  8. 22 Aug, 2014 1 commit
    • Vivek Goyal's avatar
      cgroup: Display legacy cgroup files on default hierarchy · fa8137be
      Vivek Goyal authored
      Kernel command line parameter cgroup__DEVEL__legacy_files_on_dfl forces
      legacy cgroup files to show up on default hierarhcy if susbsystem does
      not have any files defined for default hierarchy.
      
      But this seems to be working only if legacy files are defined in
      ss->legacy_cftypes. If one adds some cftypes later using
      cgroup_add_legacy_cftypes(), these files don't show up on default
      hierarchy.  Update the function accordingly so that the dynamically
      added legacy files also show up in the default hierarchy if the target
      subsystem is also using the base legacy files for the default
      hierarchy.
      
      tj: Patch description and comment updates.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      fa8137be
  9. 18 Aug, 2014 1 commit
  10. 16 Aug, 2014 22 commits