Matt Helsley <matthltc@xxxxxxxxxx> writes: > On Wed, Jun 03, 2009 at 01:15:47PM -0500, Serge E. Hallyn wrote: >> Quoting Matt Helsley (matthltc@xxxxxxxxxx): >> > On Wed, Jun 03, 2009 at 11:10:46AM -0500, Serge E. Hallyn wrote: >> > > Quoting Matt Helsley (matthltc@xxxxxxxxxx): >> > > > 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. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
