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? Oleg. - 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/
