Re: [PATCH] sched: fix another race when reading /proc/sched_debug

Bharata B Rao
2008-12-12T11:38:18Z

On Fri, Dec 12, 2008 at 3:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> kernel/sched_debug.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched_debug.c b/kernel/sched_debug.c
> index 26ed8e3..01abf5b 100644
> --- a/kernel/sched_debug.c
> +++ b/kernel/sched_debug.c
> @@ -127,8 +127,11 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
> if (tg)
> cgroup = tg->css.cgroup;
>
> - if (cgroup)
> + if (cgroup) {
> + cgroup_lock();
> cgroup_path(cgroup, path, sizeof(path));
> + cgroup_unlock();
> + }
>
> SEQ_printf(m, "\ncfs_rq[%d]:%s\n", cpu, path);
> #else
> @@ -181,8 +184,11 @@ void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq)
> if (tg)
> cgroup = tg->css.cgroup;
>
> - if (cgroup)
> + if (cgroup) {
> + cgroup_lock();
> cgroup_path(cgroup, path, sizeof(path));
> + cgroup_unlock();
> + }
>
> SEQ_printf(m, "\nrt_rq[%d]:%s\n", cpu, path);
> #else

The comment in cgroup_path() routine says that it needs to be called
with cgroup_mutex held. With the above fix, print_task() in
sched_debug.c remains the last caller of cgroup_path() which calls it
without holding cgroup_mutex. Does this also need a fix ?

Regards,
Bharata.
--