From: Mark Hills <mark@pogo.org.uk>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
linux-kernel@vger.kernel.org, balbir@linux.vnet.ibm.com
Subject: Re: cgroup: rmdir() does not complete
Date: Thu, 2 Sep 2010 10:45:01 +0100 (BST) [thread overview]
Message-ID: <alpine.NEB.2.01.1009021012360.22833@jrf.vwaro.pbz> (raw)
In-Reply-To: <20100902084200.e9b773cf.kamezawa.hiroyu@jp.fujitsu.com>
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
next prev parent reply other threads:[~2010-09-02 9:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 15:51 Mark Hills
2010-08-27 0:56 ` Daisuke Nishimura
2010-08-27 1:20 ` Balbir Singh
2010-08-27 2:35 ` KAMEZAWA Hiroyuki
2010-08-27 3:39 ` Daisuke Nishimura
2010-08-27 5:42 ` KAMEZAWA Hiroyuki
2010-08-27 6:29 ` KAMEZAWA Hiroyuki
2010-08-30 7:32 ` Balbir Singh
2010-08-30 9:13 ` Mark Hills
2010-09-01 11:10 ` Mark Hills
2010-09-01 23:42 ` KAMEZAWA Hiroyuki
2010-09-02 9:45 ` Mark Hills [this message]
2010-09-09 10:01 ` Mark Hills
2010-09-09 10:09 ` Balbir Singh
2010-09-09 11:36 ` Mark Hills
2010-09-09 11:50 ` Peter Zijlstra
2010-09-09 23:04 ` Mark Hills
2010-09-09 23:43 ` KAMEZAWA Hiroyuki
2010-09-10 2:16 ` KAMEZAWA Hiroyuki
2010-09-10 4:05 ` Daisuke Nishimura
2010-09-10 4:11 ` KAMEZAWA Hiroyuki
2010-09-10 7:28 ` Mark Hills
2010-09-10 7:33 ` KAMEZAWA Hiroyuki
2010-09-10 7:51 ` Mark Hills
2010-08-27 1:25 ` KAMEZAWA Hiroyuki
2010-08-30 9:25 ` Mark Hills
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.NEB.2.01.1009021012360.22833@jrf.vwaro.pbz \
--to=mark@pogo.org.uk \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nishimura@mxp.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®