On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
> > Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
> > threads
> >
> > Hi!
> >
> > > Kicks out a frozen thread from the refrigerator when an active thread has
> > > invoked kthread_stop on the frozen thread.
...
> > > @@ -49,7 +50,7 @@ void refrigerator(void)
> > >
> > > for (;;) {
> > > set_current_state(TASK_UNINTERRUPTIBLE);
> > > - if (!frozen(current))
> > > + if (!frozen(current) || (!current->mm && kthread_should_stop()))
> > > break;
> > > schedule();
> >
> > Well, what if the thread does some processing before stopping? That
> > would break refrigerator assumptions...
>
> The suspend thread will block until the 'to be stopped' thread clears up.
> That is what any call to kthread_stop would boil down to. The target thread
> would anyway be out of the refrigerator so I am not sure what assumption you
> mean here. Eventually, the target thread would clear up and wake up the
> suspend thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
