Re: [PATCH 2/4] cgroup freezer: Avoid lazy state changes when convenient

[Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> On Wed, Jun 03, 2009 at 01:15:47PM -0500, Serge E. Hallyn wrote:
>> Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
>> > On Wed, Jun 03, 2009 at 11:10:46AM -0500, Serge E. Hallyn wrote:
>> > > Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
>> > > >  When all the tasks of a cgroup were successfully frozen we can avoid
>> > > >  the lazy FREEZING -> FROZEN transition and move into FROZEN during the
>> > > >  write to freezer.state.
>> > > 
>> > > Can you remind us then what the point of the FREEZING state is?
>> > > It doesn't look to me like, after this patch, a cgroup will
>> > > ever be FREEZING?
>> > 
>> > FREEZING is an intermediate state indicating that the cgroup is
>> > partially frozen and, unless userspace retries, it will remain so. 
>> 
>> Oh, so basically a cgroup will be in CGROUP_FREEZING state only
>> while try_to_freeze_cgroup() is looping over the tasks now?
>
> Not quite. freeze_task() can fail because of vfork. If it fails we do
> some additional checks to make sure it'll eventually be freezable. If so
> then we know we missed one. That's when it stays in the FREEZING
> state until the next time userspace writes FROZEN or THAWED to freezer.state.

Not really a comment on your patch, but some puzzlement regarding this
treatment of vfork.

I see how the do_fork code makes the freezer skip a task which is
waiting in vfork.  But is there anything preventing a vfork'd child from
being frozen (e.g. before it execs or exits)?  As far as I can tell this
isn't prevented, but perhaps it should be, since the parent cannot enter
frozen state until after the child has called mm_release.

Does the FREEZING state in cgroup_freezer.c exist solely for the sake of
vfork?  If so, it would help reviewers quite a bit to have that
documented in the code.