All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dasgupta, Romit" <romit@ti.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@lists.linux-foundation.org" 
	<linux-pm@lists.linux-foundation.org>
Subject: RE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Date: Sun, 8 Nov 2009 16:30:40 +0530	[thread overview]
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301DE31FD0F@dbde02.ent.ti.com> (raw)
In-Reply-To: <20091108082727.GC16482@elf.ucw.cz>



> -----Original Message-----
> From: Pavel Machek [mailto:pavel@ucw.cz]
> Sent: Sunday, November 08, 2009 1:57 PM
> To: Dasgupta, Romit
> Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-pm@lists.linux-foundation.org
> Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
> 
> 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?

evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This should be followed by a call to kthread_should_stop. There it decides if it needs to exit the thread (after cleanups if necessary) or not. I have seen that the bdi_writeback_task function is like that. It does not care if there is pending data to be written if it detects that someone have invoked a 'kthread_stop' on it. It simply exits. I have seen some other kernel threads that do not follow this and I think that probably is not right. 

  reply	other threads:[~2009-11-08 11:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06  9:36 [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads Dasgupta, Romit
2009-11-06  9:36 ` Dasgupta, Romit
2009-11-07 16:54 ` Pavel Machek
2009-11-07 16:54 ` Pavel Machek
2009-11-07 16:54   ` Pavel Machek
2009-11-08  4:22   ` Dasgupta, Romit
2009-11-08  4:22     ` Dasgupta, Romit
2009-11-08  8:27     ` Pavel Machek
2009-11-08  8:27       ` Pavel Machek
2009-11-08 11:00       ` Dasgupta, Romit [this message]
2009-11-08 11:00         ` Dasgupta, Romit
2009-11-08 11:00       ` Dasgupta, Romit
2009-11-08 11:10       ` Dasgupta, Romit
2009-11-08 11:10         ` Dasgupta, Romit
2009-11-09  8:31         ` Pavel Machek
2009-11-09  8:31         ` Pavel Machek
2009-11-09  8:31           ` Pavel Machek
2009-11-09  9:18           ` Dasgupta, Romit
2009-11-09  9:18             ` Dasgupta, Romit
2009-11-09 12:06             ` Rafael J. Wysocki
2009-11-09 12:06               ` Rafael J. Wysocki
2009-11-09 12:06             ` Rafael J. Wysocki
2009-11-08 11:10       ` Dasgupta, Romit
2009-11-08  8:27     ` Pavel Machek
2009-11-08  4:22   ` Dasgupta, Romit
  -- strict thread matches above, loose matches on Subject: below --
2009-11-06  9:36 Dasgupta, Romit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B85A65D85D7EB246BE421B3FB0FBB59301DE31FD0F@dbde02.ent.ti.com \
    --to=romit@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.