[lkml]   [2007]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 1/3] Freezer: Fix vfork problem
On Tue, Feb 27, 2007 at 10:03:53AM +0530, Aneesh Kumar wrote:
> This means that we are not going to wait for the kernel thread
> (Parent) to freeze. I guess what vatsa suggested in previous mail is
> better.
> freeezer_do_not_count(void)
> {
> if (current->mm) {
> current->flags |= PF_FREEZER_SKIP;
> }
> }
> freezer_count(void)
> {
> if (current->mm) {
> current->flags &= ~PF_FREEZER_SKIP;
> try_to_freeze();
> }
> }
> Now if do_fork is called from kernel_thread with CLONE_VFORK we make
> the freezer wait till that kernel thread is also frozen. I think this
> is important. with khelper thread it is okey because it is a single
> threaded workqueue.

Yes, this assumes that vfork called by a kernel thread will usually wait
only until the vfork child exec's (and not until the child exit's).
That wait should be very short and hence we can wait for vfork parent as

The advanatge of this is we let kernel threads get to freeze at a place of
their choice (rather than in some common code like do_fork).

> If do_fork is called via a user process we can skip the Parent if the
> child got frozen before calling execve.

Yes, agreed.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-27 05:45    [W:0.066 / U:1.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site