The above commit fixed a race that reading /proc/sched_debug may accessNULL cgrp->dentry if a cgroup is being removed (via cgroup_rmdir), buthasn't been destroyed (via cgroup_diput).

But I found there's another different race, in that reading sched_debugmay access a cgroup which is being created or has been destroyed, and thusdereference NULL cgrp->dentry!

task_group is added to the global list while the cgroup is being created,and is removed from the global list while the cgroup is under destruction.So running through the list should be protected by cgroup_lock(), ifcgroup data will be accessed (here by calling cgroup_path).