[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: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()). 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). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King -
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Justin C. Sherrill | Mailing list archive |
| Ingo Molnar | [patch 08/13] syslets: x86, add move_user_context() method |
git: | |
| Steven Rostedt | Re: -rt scheduling: wakeup bug? |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
