From: "tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: shyju pv <shyju.pv-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Sanil kumar <sanil.kumar-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Masanari Iida
<standby24x7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
Date: Fri, 29 Jun 2012 09:58:09 -0700 [thread overview]
Message-ID: <20120629165809.GB21048@google.com> (raw)
In-Reply-To: <4FED10DB.7040500-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hey,
On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
> > Can you please elaborate a bit? I'm not really following? Where does
> > the last root->d_count-- come from?
>
>
> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>
> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
> dentry is still > 0.
Heh, yeah, I thought you found who was holding out on the refcnt. :)
> >> I use this script to reproduce the bug:
> >>
> >> mount -t cgroup -o cpu xxx /mnt
> >> mkdir /mnt/sub
> >> sleep 100 < /mnt/sub &
> >> kill $!
> >> wait $!
> >> rmdir /mnt/sub
> >> umount /mnt
> > Unfortunately, this doesn't reproduce the bug here either. :(
>
> I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
> cgroup files?
Hmm... weird. Maybe some debug config option I have is preventing the
race from occurring as reliably? Can you please attach your .config?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: "tj@kernel.org" <tj@kernel.org>
To: Li Zefan <lizefan@huawei.com>
Cc: shyju pv <shyju.pv@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
Sanil kumar <sanil.kumar@huawei.com>,
Masanari Iida <standby24x7@gmail.com>
Subject: Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
Date: Fri, 29 Jun 2012 09:58:09 -0700 [thread overview]
Message-ID: <20120629165809.GB21048@google.com> (raw)
In-Reply-To: <4FED10DB.7040500@huawei.com>
Hey,
On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
> > Can you please elaborate a bit? I'm not really following? Where does
> > the last root->d_count-- come from?
>
>
> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>
> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
> dentry is still > 0.
Heh, yeah, I thought you found who was holding out on the refcnt. :)
> >> I use this script to reproduce the bug:
> >>
> >> mount -t cgroup -o cpu xxx /mnt
> >> mkdir /mnt/sub
> >> sleep 100 < /mnt/sub &
> >> kill $!
> >> wait $!
> >> rmdir /mnt/sub
> >> umount /mnt
> > Unfortunately, this doesn't reproduce the bug here either. :(
>
> I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
> cgroup files?
Hmm... weird. Maybe some debug config option I have is preventing the
race from occurring as reliably? Can you please attach your .config?
Thanks.
--
tejun
next prev parent reply other threads:[~2012-06-29 16:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-24 19:08 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup] shyju pv
2012-06-24 19:08 ` shyju pv
[not found] ` <E061084CB90FCE4F89232A6CF839683B32B52291-SY/3K1LPFSqBBfbIEMVH7QK1hpo4iccwjNknBlVQO8k@public.gmane.org>
2012-06-26 23:00 ` Masanari Iida
2012-06-26 23:00 ` Masanari Iida
2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-27 18:29 ` tj
[not found] ` <20120627182903.GP15811-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-06-27 23:02 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-27 23:02 ` tj
[not found] ` <20120627230230.GT15811-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-06-28 14:09 ` Masanari Iida
2012-06-28 14:09 ` Masanari Iida
2012-06-28 6:07 ` Li Zefan
2012-06-28 6:07 ` Li Zefan
[not found] ` <4FEBF4B7.2070105-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-06-28 18:07 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-28 18:07 ` tj
[not found] ` <20120628180712.GC22641-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-06-29 2:20 ` Li Zefan
2012-06-29 2:20 ` Li Zefan
[not found] ` <4FED10DB.7040500-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-06-29 16:58 ` tj-DgEjT+Ai2ygdnm+yROfE0A [this message]
2012-06-29 16:58 ` tj
2012-06-29 18:07 ` Masanari Iida
[not found] ` <20120629165809.GB21048-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-06-30 6:13 ` Li Zefan
2012-06-30 6:13 ` Li Zefan
[not found] ` <4FEE98EE.1050409-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-06-30 6:47 ` Al Viro
2012-06-30 6:47 ` Al Viro
[not found] ` <20120630064724.GC14083-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2012-06-30 7:04 ` Tejun Heo
2012-06-30 7:04 ` Tejun Heo
[not found] ` <CAOS58YNnU3J+c2ZQcRCesSoxn0dSJjDLBsZ2qzZ09X6N-ky0fQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-30 8:34 ` Al Viro
2012-06-30 8:34 ` Al Viro
[not found] ` <20120630083421.GD14083-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2012-07-03 17:10 ` Tejun Heo
2012-07-03 17:10 ` Tejun Heo
[not found] ` <20120703171033.GC555-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-07-03 17:38 ` [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode Tejun Heo
2012-07-03 17:38 ` Tejun Heo
[not found] ` <20120703173806.GD555-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-07-04 5:40 ` Li Zefan
2012-07-04 5:40 ` Li Zefan
[not found] ` <4FF3D757.9060905-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-07-09 17:11 ` Tejun Heo
2012-07-09 17:11 ` Tejun Heo
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=20120629165809.GB21048@google.com \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=sanil.kumar-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=shyju.pv-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=standby24x7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.