Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932939AbXAaPsl (ORCPT ); Wed, 31 Jan 2007 10:48:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932936AbXAaPsl (ORCPT ); Wed, 31 Jan 2007 10:48:41 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:49390 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932950AbXAaPsk (ORCPT ); Wed, 31 Jan 2007 10:48:40 -0500 Date: Wed, 31 Jan 2007 10:48:38 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Rafael J. Wysocki" cc: Oliver Neukum , pm list , Subject: Re: [linux-pm] question on resume() In-Reply-To: <200701310933.29443.rjw@sisk.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2741 Lines: 57 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. > > 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. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/