linux-kernel - Re: [linux-pm] question on resume()

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: <Pine.LNX.4.44L0.0701311042340.3803-100000@iolanthe.rowland.org>
Date:	Wed, 31 Jan 2007 10:48:38 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Oliver Neukum <oliver@...kum.name>,
	pm list <linux-pm@...ts.osdl.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] question on resume()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/