On 02/20, Rafael J. Wysocki wrote:
>
> On Monday, 19 February 2007 23:41, Oleg Nesterov wrote:
> > On 02/19, Rafael J. Wysocki wrote:
> > >
> > > On Monday, 19 February 2007 21:23, Oleg Nesterov wrote:
> > >
> > > > > @@ -199,6 +189,10 @@ static void thaw_tasks(int thaw_user_spa
> > > > >
> > > > > do_each_thread(g, p) {
> > > > > + if (freezer_should_skip(p))
> > > > > + cancel_freezing(p);
> > > > > + } while_each_thread(g, p);
> > > > > + do_each_thread(g, p) {
> > > > > if (!freezeable(p))
> > > > > continue;
> > > >
> > > > Any reason for 2 separate do_each_thread() loops ?
> > >
> > > Yes. If there is a "freeze" request pending for the vfork parent
> > > (TIF_FREEZE
> > > set), we have to cancel it before the child is unfrozen, since otherwise
> > > the
> > > parent may go freezing after we try to reset PF_FROZEN for it.
> >
> > I see, thanks... thaw_process() doesn't take TIF_FREEZE into account.
> >
> > But doesn't this mean we have a race?
> >
> > Suppose that try_to_freeze_tasks() failed. It does cancel_freezing() for
> > each
> > process before return, but what if some thread already checked TIF_FREEZE
> > and
> > (for simplicity) it is preempted before frozen_process() in refrigerator().
> >
> > thaw_tasks() runs, ignores this task (P), returns. P gets CPU, and becomes
> > frozen, but nobody will thaw it.
> >
> > No?
>
> Well, I think this is highly theoretical. Namely, try_to_freeze_tasks() only
> fails after the timeout that's currently set to 20 sec., and it yields the CPU
> in each iteration of the main loop. The task in question would have to refuse
> being frozen for 20 sec. and then suddenly decide to freeze itself right
> before
> try_to_freeze_tasks() checks the timeout for the very last time. Then, it
> would have to get preempted at this very moment and stay unfrozen at least
> until thaw_tasks() starts running and in fact even longer.
Yes, yes, it is pure theroretical,
> I think we may avoid this by making try_to_freeze_tasks() sleep for some time
> after it has reset TIF_FREEZE for all tasks in the error path, if anyone is
> ever able to trigger it.
This makes this race (pure theroretical) ** 2 :)
Still. May be it make sense to introduce cancel_freezing_and_thaw() function
(not right now) which stops the task from sleeping in refrigirator reliably.
I didn't think much about this, but it looks like we can fix coredump/exec
problems. Of course, this is not so important, we can ignore them at least
for now (->vfork_done is different, should be imho solved, because any user
can block freezer forever).
The fix:
refrigerator:
+ // we are going to call do_exit() really soon,
+ // we have a pending SIGKILL
+ if (current->signal->flags & SIGNAL_GROUP_EXIT)
+ return;
frozen_process(current);
...
zap_other_threads:
for_each_subthread() {
...
+ // ---- SIGNAL_GROUP_EXIT is set ------
+ // we can check sig->group_exit_task to detect
de_thread,
+ // but perhaps it doesn't hurt if the caller is
do_group_exit
+ cancel_freezing_and_thaw(p);
sigaddset(&t->pending.signal, SIGKILL);
signal_wake_up(t, 1);
}
This way execer reliably kills all sub-threads and proceeds without blocking
try_to_freeze_tasks(). The same change could be done for zap_process() to fix
coredump.
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/
