Re: cgroup: rmdir() does not complete

[Mark Hills]

On Thu, 2 Sep 2010, KAMEZAWA Hiroyuki wrote:

> On Wed, 1 Sep 2010 12:10:23 +0100 (BST)
> Mark Hills <mark@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/