[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070219224141.GB5070@tv-sign.ru>
Date: Tue, 20 Feb 2007 01:41:41 +0300
From: Oleg Nesterov <oleg@...sign.ru>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: ego@...ibm.com, akpm@...l.org, paulmck@...ibm.com, mingo@...e.hu,
vatsa@...ibm.com, dipankar@...ibm.com,
venkatesh.pallipadi@...el.com, linux-kernel@...r.kernel.org,
Pavel Machek <pavel@....cz>
Subject: Re: freezer problems
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?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists