lkml.org 
[lkml]   [2010]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: cgroup: rmdir() does not complete
On Thu, 2 Sep 2010, KAMEZAWA Hiroyuki wrote:

> On Wed, 1 Sep 2010 12:10:23 +0100 (BST)
> Mark Hills <mark@pogo.org.uk> wrote:
[...]
> > I repeated the test above, but did not see a problem after many hundreds
> > of loops.
> >
> > My test was with the same kernel from my original bug report (Fedora
> > 2.6.33.6-147), using memory cgroup only and ext4 filesystem.
> >
> > So it is possible we are experiencing different bugs with similar
> > symptoms.
> >
>
> Thank you for confirming.
> But hmm...it's curious who holds mutex and what happens.

Refer to my original email, where I was running multiple tests at once.
This backtrace is from the tests which queue up:

Call Trace:
[<ffffffff81115edb>] ? mntput_no_expire+0x24/0xe7
[<ffffffff81427acd>] __mutex_lock_common+0x14d/0x1b4
[<ffffffff81108a7c>] ? path_put+0x1d/0x22
[<ffffffff81427b48>] __mutex_lock_slowpath+0x14/0x16
[<ffffffff81427c4f>] mutex_lock+0x31/0x4b
[<ffffffff8110bdf8>] do_rmdir+0x74/0x102
[<ffffffff8110bebd>] sys_rmdir+0x11/0x13
[<ffffffff81009b02>] system_call_fastpath+0x16/0x1b

The one which spins has already managed to claim the mutex lock on the
/cgroup directory, and no call trace is shown for this. Is there a usable
way to force a similar call trace for the spinning process?

Unfortunately I have not been able to reproduce the problem for some days
now, so I think some network factor is able to influence this.

--
Mark


\
 
 \ /
  Last update: 2010-09-02 11:47    [W:0.105 / U:15.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site