linux-kernel - Re: cgroup: rmdir() does not complete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Sep 2010 10:45:01 +0100 (BST)
From:	Mark Hills <mark@...o.org.uk>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
cc:	Daisuke Nishimura <nishimura@....nes.nec.co.jp>,
	linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com
Subject: Re: 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@...o.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/