linux-kernel - Re: freezer problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200702200132.12847.rjw@sisk.pl>
Date:	Tue, 20 Feb 2007 01:32:11 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Oleg Nesterov <oleg@...sign.ru>
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 Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
> 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.

Hm.  In the case discussed above we have a task that's right before calling
frozen_process(), so we can't thaw it, because it's not frozen.  It will be
frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have no
way to check this.

I think to close this race the refrigerator should check TIF_FREEZE and set
PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
taken by try_to_freeze_tasks() in the beginning of the error path.  This will
ensure that all tasks either freeze themselves before the error path in
try_to_freeze_tasks() is executed, or remain unfrozen.

I'll try to prepare a patch to illustrate this, but right now I'm too tired to
do it. :-)

> 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.

Yes, at first sight it looks good.

BTW, what do you think of the updated patch I sent two messages ago?

Rafael
-
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/