Re: [Fwd: Re: cgroup umount bug]

Re: [Fwd: Re: cgroup umount bug]

[handai handai]

> From: "Serge E. Hallyn" <serge@hallyn.com>
> To: 含黛 <handai.szj@taobao.com>
> Date: Sat, 8 Oct 2011 18:18:13 +0000
> Subject: Re: cgroup umount bug
> Quoting 含黛 (handai.szj@taobao.com):
>> Hi,
>>
>>     I found a mount/umount problem while using cgroup: I mount a cpu
>> cgroup (or other subsystems) and create some subgroups under it, but
>> later I try to umount it without rmdir those subgroups. I find that I
>> can umount it without any errors but actually the super block still
>> exist. This is because the sb->s_active count is greater than 1 which
>> was added by cgroup_create. But later if I want to mount both cpu and
>> memory subsystems, it will be unsuccessful indicating that the
>> device(cpu subsystem) is busy. This situation will not happen if I rmdir
>> the subgroups manually before umount it. So my question is:
>>     Should the umount return success when there are still some subgroups
>
> Yes.  The fs was unmounted from that directory.
>
>> exist ? If this is okay, then it may lead to some *strange* errors using
>> cgroup later. If it can not be umount, then it should inform that the
>> mount point is still busy.
>
>> Following is an example of this problem:
>>
>> mount -t cgroup -o cpu cgroup /mnt
>> mkdir /mnt/test
>>
>> .....// do some tests
>>
>> umount /mnt      /* return successfully */
>>
>> /* do other subsystems test */
>> mount -cgroup -o cpu,cpuset cgroup /mnt
>> mount: cgroup already mounted or /mnt busy  /*??? which is strange */
>
> I'm not sure from what you write whether you're aware of this, but
> to work around this, you can then
>
>  mount -t cgroup -o cpu /mnt
>  for i in `cat /mnt/test/tasks`; do
>  echo $i > /mnt/tasks
>  done
>  rmdir /mnt/test
>  umount /mnt
>
> and now you can
>
>  mount -cgroup -o cpu,cpuset cgroup /mnt
>

I know that I can bypass this problem by deleting subgroups before
unmount. But there is no document mentioning that I should do this to
avoid it. But even if there is, users may still directly umount it
accidentally, then he should try to remember what he has done and back
to the scene to make it up, or he may need to reboot his server to do
another test : ( .
So, since there is nothing good to permit incompletely unmount, why
not prevent the potential problem by prohibiting this behavior at
first ?

Best regards,
sha


> Being unable to umount /mnt while child cgroups exist or having all
> child cgroups cleared and removed automatically would both be less
> useful behaviors.
>
> thanks,
> -serge
>
>

Re: [Fwd: Re: cgroup umount bug]

[Serge E. Hallyn]

Quoting handai handai (handai.szj@gmail.com):
> From: "Serge E. Hallyn" <serge@hallyn.com>
> > To: 含黛 <handai.szj@taobao.com>
> > Date: Sat, 8 Oct 2011 18:18:13 +0000
> > Subject: Re: cgroup umount bug
> > Quoting 含黛 (handai.szj@taobao.com):
> > > Hi,
> > >
> > >     I found a mount/umount problem while using cgroup: I mount a cpu
> > > cgroup (or other subsystems) and create some subgroups under it, but
> > > later I try to umount it without rmdir those subgroups. I find that I
> > > can umount it without any errors but actually the super block still
> > > exist. This is because the sb->s_active count is greater than 1 which
> > > was added by cgroup_create. But later if I want to mount both cpu and
> > > memory subsystems, it will be unsuccessful indicating that the
> > > device(cpu subsystem) is busy. This situation will not happen if I rmdir
> > > the subgroups manually before umount it. So my question is:
> > >     Should the umount return success when there are still some subgroups
> >
> > Yes.  The fs was unmounted from that directory.
> >
> > > exist ? If this is okay, then it may lead to some *strange* errors using
> > > cgroup later. If it can not be umount, then it should inform that the
> > > mount point is still busy.
> >
> > > Following is an example of this problem:
> > >
> > > mount -t cgroup -o cpu cgroup /mnt
> > > mkdir /mnt/test
> > >
> > > …..// do some tests
> > >
> > > umount /mnt      /* return successfully */
> > >
> > > /* do other subsystems test */
> > > mount -cgroup -o cpu,cpuset cgroup /mnt
> > > mount: cgroup already mounted or /mnt busy  /*??? which is strange */
> >
> > I'm not sure from what you write whether you're aware of this, but
> > to work around this, you can then
> >
> >  mount -t cgroup -o cpu /mnt
> >  for i in `cat /mnt/test/tasks`; do
> >  echo $i > /mnt/tasks
> >  done
> >  rmdir /mnt/test
> >  umount /mnt
> >
> > and now you can
> >
> >  mount -cgroup -o cpu,cpuset cgroup /mnt
> >
> 
> 
> I know that I can bypass this problem by deleting subgroups before unmount.

Or (my point was) after remount.

> But there is no document mentioning that I should do this to avoid it. But

Patches to Documentation/ are welcom.

> even if there is, users may still directly umount it accidentally, then he
> should try to remember what he has done and back to the scene to make it up,

It's not just any user, it's the admin.  If he's not paying attention to
what he's doing, you've got problems.

> or he may need to reboot his server to do another test : ( .
> So, since there is nothing good to permit incompletely unmount,

I disagree.

>  why not
> prevent the potential problem by prohibiting this behavior at first ?

-serge

Re: [Fwd: Re: cgroup umount bug]

[Li Zefan]

>> I'm not sure from what you write whether you're aware of this, but
>> to work around this, you can then
>>
>>  mount -t cgroup -o cpu /mnt
>>  for i in `cat /mnt/test/tasks`; do
>>  echo $i > /mnt/tasks
>>  done
>>  rmdir /mnt/test
>>  umount /mnt
>>
>> and now you can
>>
>>  mount -cgroup -o cpu,cpuset cgroup /mnt
>>
> 
> I know that I can bypass this problem by deleting subgroups before
> unmount. But there is no document mentioning that I should do this to
> avoid it. But even if there is, users may still directly umount it
> accidentally, then he should try to remember what he has done and back
> to the scene to make it up, or he may need to reboot his server to do
> another test : ( .

You can check /proc/cgroups:

# mount -t cgroup -o cpu,cpuset cgroup /mnt
# mkdir /mnt/sub
# umount /mnt
# cat /proc/cgroups 
#subsys_name    hierarchy       num_cgroups     enabled
cpuset  1       2       1
cpu     1       2       1
memory  0       1       1
devices 0       1       1
freezer 0       1       1
net_cls 0       1       1
blkio   0       1       1

> So, since there is nothing good to permit incompletely unmount, why
> not prevent the potential problem by prohibiting this behavior at
> first ?
>