From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oliver@neukum.name>,
pm list <linux-pm@lists.osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] question on resume()
Date: Wed, 31 Jan 2007 19:52:36 +0100 [thread overview]
Message-ID: <200701311952.36736.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0701311042340.3803-100000@iolanthe.rowland.org>
On Wednesday, 31 January 2007 16:48, Alan Stern wrote:
> On Wed, 31 Jan 2007, Rafael J. Wysocki wrote:
>
> > On Tuesday, 30 January 2007 23:32, Rafael J. Wysocki wrote:
> > > [Added linux-pm to the Cc list, because I'm going to talk about things that
> > > I know only from reading the code.]
> > >
> > > On Tuesday, 30 January 2007 17:50, Oliver Neukum wrote:
> > > > Am Dienstag, 30. Januar 2007 17:32 schrieb Rafael J. Wysocki:
> > > > > However, you can always inspect the PF_FROZEN flag of the tasks in question
> > > > > if that's practicable.
> > > >
> > > > What would I do with that information? Ignore completion of IO?
> > >
> > > I probably should say "that depends", but that wouldn't be very helpful.
> > >
> > > Getting back to your initial question, which is if wake_up() may be called
> > > from a driver's .resume() routine, I think the answer is no, it may not,
> > > because in that case the "notified" tasks would be removed from the wait
> > > queue, but the refrigerator() would (wrongly) restore their states as
> > > TASK_UNINTERRUPTIBLE (or TASK_INTERRUPTIBLE for wake_up_interruptible()).
>
> Even though I'm late to this thread, here are some additional thoughts...
>
> Rafael is wrong; wake_up() doesn't remove a task from a wait queue. It
> makes the task runnable, and then the task removes itself from the wait
> queue after verifying that the necessary condition has been satisfied.
>
> Thus calling wake_up() on a task in the refrigerator will accomplish
> nothing -- no good and no harm. The task will remain frozen, and when it
> is unfrozen it will realize that the condition has been satisfied and will
> remove itself from the wait queue.
That's the point I wasn't quite sure of.
> > > Generally, you are safe if your driver only calls wake_up() from a process
> > > context, but not from .resume() or .suspend() routines (or from an
> > > unfreezeable kernel thread).
> >
> > Ah, sorry, I've just realized I was wrong. Processes in TASK_UNINTERRUPTIBLE
> > cannot be frozen! So, the above only applies to wake_up_interruptible().
> >
> > You don't need to call wake_up() from .resume(), because there are no tasks
> > to be notified this way and you shouldn't call wake_up_interruptible() from
> > there.
>
> While it's true that one doesn't need to call wake_up() from .resume(),
> you are overlooking the point of Oliver's question. .resume() can start
> up an I/O operation which can then complete before the tasks are
> defrosted. The I/O's completion routine generally _will_ end up calling
> wake_up() on some still-frozen task. That's just as bad as calling it
> yourself from within the resume routine.
Okay, but since the tasks remove themselves from wait queues, there's no
problem here. :-)
Greetings,
Rafael
--
If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
prev parent reply other threads:[~2007-01-31 18:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 11:06 question on resume() Oliver Neukum
2007-01-29 11:24 ` Nigel Cunningham
2007-01-29 11:34 ` Oliver Neukum
2007-01-29 20:14 ` Nigel Cunningham
2007-01-29 21:04 ` Oliver Neukum
2007-01-29 21:21 ` Nigel Cunningham
2007-01-29 23:10 ` Rafael J. Wysocki
2007-01-30 16:32 ` Rafael J. Wysocki
2007-01-30 16:50 ` Oliver Neukum
2007-01-30 22:32 ` Rafael J. Wysocki
2007-01-30 22:32 ` Rafael J. Wysocki
2007-01-31 8:33 ` Rafael J. Wysocki
2007-01-31 8:33 ` Rafael J. Wysocki
2007-01-31 8:40 ` Oliver Neukum
2007-01-31 8:40 ` Oliver Neukum
2007-01-31 8:49 ` Rafael J. Wysocki
2007-01-31 9:04 ` Oliver Neukum
2007-01-31 9:04 ` Oliver Neukum
2007-01-31 9:36 ` Pavel Machek
2007-01-31 9:36 ` [linux-pm] " Pavel Machek
2007-01-31 10:14 ` Oliver Neukum
2007-01-31 10:14 ` [linux-pm] " Oliver Neukum
2007-01-31 10:30 ` Pavel Machek
2007-01-31 15:54 ` Alan Stern
2007-01-31 15:54 ` [linux-pm] " Alan Stern
2007-01-31 16:12 ` Oliver Neukum
2007-01-31 16:12 ` [linux-pm] " Oliver Neukum
2007-01-31 16:27 ` Alan Stern
2007-01-31 16:27 ` [linux-pm] " Alan Stern
2007-01-31 18:04 ` Woodruff, Richard
2007-01-31 18:04 ` [linux-pm] " Woodruff, Richard
2007-01-31 15:48 ` Alan Stern
2007-01-31 15:48 ` [linux-pm] " Alan Stern
2007-01-31 18:52 ` Rafael J. Wysocki [this message]
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=200701311952.36736.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=oliver@neukum.name \
--cc=stern@rowland.harvard.edu \
/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.