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

Ingo Molnar
2008-12-16T12:24:24Z

* Li Zefan <lizf@cn.fujitsu.com> wrote:

> Li Zefan wrote:
> >> i merged it up in tip/master, could you please check whether it's ok?
> >>
> >
> > Sorry, though this patch avoids accessing a half-created cgroup, but I found
> > current code may access a cgroup which has been destroyed.
> >
> > The simplest fix is to take cgroup_lock() before for_each_leaf_cfs_rq.
> >
> > Could you revert this patch and apply the following new one? My box has
> > survived for 16 hours with it applied.
> >
>
> Hi, Ingo
>
> Can we have this bug fixed for 2.6.28 using this patch ? This patch is
> the simplest fix and has been fully tested.

the mutex used by cgroup_lock() is pretty crappy to nest inside the
runqueue lock:

BUG: sleeping function called from invalid context at kernel/mutex7
in_atomic(): 0, irqs_disabled(): 1, pid: 1790, name: cat
2 locks held by cat/1790:
#0: (&p->lock){--..}, at: [<c02a6328>] seq_read+0x25/0x2b8
#1: (tasklist_lock){..--}, at: [<c021f5bc>]
sched_debug_show+0xaa7/0xe90
Call Trace:
[<c0222612>] __might_sleep+0xd6/0xdd
[<c05ff1eb>] mutex_lock_nested+0x1d/0x245
[<c021f88b>] ? sched_debug_show+0xd76/0xe90
[<c0256223>] cgroup_lock+0xf/0x11
[<c021f893>] sched_debug_show+0xd7e/0xe90
[<c0248696>] ? __lock_acquire+0x637/0x69d
[<c028e7cd>] ? check_object+0x111/0x18c
[<c028f435>] ? kmem_cache_alloc+0x70/0xa5
[<c02a6355>] ? seq_read+0x52/0x2b8
[<c0246ee2>] ? trace_hardirqs_on_caller+0x105/0x13d
[<c0246f25>] ? trace_hardirqs_on+0xb/0xd
[<c02a6355>] ? seq_read+0x52/0x2b8
[<c02a63f7>] seq_read+0xf4/0x2b8
[<c02a6303>] ? seq_read+0x0/0x2b8
[<c02c411a>] proc_reg_read+0x60/0x74

so i had to remove your patch.

also, while looking at what cgroup_lock does - it's a trivial wrapper:

void cgroup_lock(void)
{
mutex_lock(&cgroup_mutex);
}

why isnt that done explicitly in all usage sites? If cgroup-unaware code
ever has to take the cgroup lock outside of CONFIG_CGROUPS, that's a code
structure problem.

Ingo