On Sunday, 18 February 2007 17:11, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > > > > > > > > A very vague idea: what if parent will do > > > > > > > > current->flags |= > > > > PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > > > > wait_for_completion(&vfork); > > > > try_to_freeze(); > > > > > > > > ? > > > > Hm, what about the following patch instead? > > > > The problem is that if the child enters the refrigeratior, we can't freeze > > the > > parent, because it's uninterruptible, but the child knows the parent will be > > uninterruptible until it exits, so the child can mark the parent as frozen. > > > > --- linux-2.6.20-mm2.orig/kernel/power/process.c 2007-02-18 > > 15:43:30.000000000 +0100 > > +++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-18 16:09:53.000000000 > > +0100 > > @@ -39,6 +39,13 @@ void refrigerator(void) > > /* Hmm, should we be allowed to suspend when there are realtime > > processes around? */ > > long save; > > + > > + /* The parent is uninterruptible and will stay so until this task exits, > > + * so we can mark it as frozen. > > + */ > > + if (current->vfork_done) > > + frozen_process(current->parent); > > This is not safe. task->flags is not atomic, we can change ->flags only > if we know the task won't touch it itself (ptrace, thaw_process). > The parent could be interrupted, irq may play with current->flags (slab, > for example). > > Please note that ->parent may do things like ptrace_notify() before > it actually sleeps on ->vfork_done. This means that even if we could > set PF_FROZEN in a safe manner, this doesn't look like a good idea. > > > + > > + if (current->vfork_done && frozen(current->parent)) > > + current->parent->flags &= ~PF_FROZEN; > > } > > Why? If the code above works, we shouldn't take care about frozen > ->parent?
I've added this for symmetry. thaw_tasks() should reset PF_FROZEN for it anyway. Okay, so I'll post the patch that implements your idea in the other thread. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
