alistair23-linux/include/linux/freezer.h

134 lines
3.5 KiB
C
Raw Normal View History

/* Freezer declarations */
[PATCH] freezer.h uses task_struct fields freezer.h uses task_struct fields so it should include sched.h. CC [M] fs/jfs/jfs_txnmgr.o In file included from fs/jfs/jfs_txnmgr.c:49: include/linux/freezer.h: In function 'frozen': include/linux/freezer.h:9: error: dereferencing pointer to incomplete type include/linux/freezer.h:9: error: 'PF_FROZEN' undeclared (first use in this function) include/linux/freezer.h:9: error: (Each undeclared identifier is reported only once include/linux/freezer.h:9: error: for each function it appears in.) include/linux/freezer.h: In function 'freezing': include/linux/freezer.h:17: error: dereferencing pointer to incomplete type include/linux/freezer.h:17: error: 'PF_FREEZE' undeclared (first use in this function) include/linux/freezer.h: In function 'freeze': include/linux/freezer.h:26: error: dereferencing pointer to incomplete type include/linux/freezer.h:26: error: 'PF_FREEZE' undeclared (first use in this function) include/linux/freezer.h: In function 'do_not_freeze': include/linux/freezer.h:34: error: dereferencing pointer to incomplete type include/linux/freezer.h:34: error: 'PF_FREEZE' undeclared (first use in this function) include/linux/freezer.h: In function 'thaw_process': include/linux/freezer.h:43: error: dereferencing pointer to incomplete type include/linux/freezer.h:43: error: 'PF_FROZEN' undeclared (first use in this function) include/linux/freezer.h:44: warning: implicit declaration of function 'wake_up_process' include/linux/freezer.h: In function 'frozen_process': include/linux/freezer.h:55: error: dereferencing pointer to incomplete type include/linux/freezer.h:55: error: dereferencing pointer to incomplete type include/linux/freezer.h:55: error: 'PF_FREEZE' undeclared (first use in this function) include/linux/freezer.h:55: error: 'PF_FROZEN' undeclared (first use in this function) fs/jfs/jfs_txnmgr.c: In function 'freezing': include/linux/freezer.h:18: warning: control reaches end of non-void function make[2]: *** [fs/jfs/jfs_txnmgr.o] Error 1 Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-10 03:18:58 -07:00
#include <linux/sched.h>
#ifdef CONFIG_PM
/*
* Check if a process has been frozen
*/
static inline int frozen(struct task_struct *p)
{
return p->flags & PF_FROZEN;
}
/*
* Check if there is a request to freeze a process
*/
static inline int freezing(struct task_struct *p)
{
[PATCH] PM: Fix SMP races in the freezer Currently, to tell a task that it should go to the refrigerator, we set the PF_FREEZE flag for it and send a fake signal to it. Unfortunately there are two SMP-related problems with this approach. First, a task running on another CPU may be updating its flags while the freezer attempts to set PF_FREEZE for it and this may leave the task's flags in an inconsistent state. Second, there is a potential race between freeze_process() and refrigerator() in which freeze_process() running on one CPU is reading a task's PF_FREEZE flag while refrigerator() running on another CPU has just set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If the refrigerator wins the race, freeze_process() will state that PF_FREEZE hasn't been set for the task and will set it unnecessarily, so the task will go to the refrigerator once again after it's been thawed. To solve first of these problems we need to stop using PF_FREEZE to tell tasks that they should go to the refrigerator. Instead, we can introduce a special TIF_*** flag and use it for this purpose, since it is allowed to change the other tasks' TIF_*** flags and there are special calls for it. To avoid the freeze_process()-refrigerator() race we can make freeze_process() to always check the task's PF_FROZEN flag after it's read its "freeze" flag. We should also make sure that refrigerator() will always reset the task's "freeze" flag after it's set PF_FROZEN for it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 01:34:30 -07:00
return test_tsk_thread_flag(p, TIF_FREEZE);
}
/*
* Request that a process be frozen
*/
static inline void freeze(struct task_struct *p)
{
[PATCH] PM: Fix SMP races in the freezer Currently, to tell a task that it should go to the refrigerator, we set the PF_FREEZE flag for it and send a fake signal to it. Unfortunately there are two SMP-related problems with this approach. First, a task running on another CPU may be updating its flags while the freezer attempts to set PF_FREEZE for it and this may leave the task's flags in an inconsistent state. Second, there is a potential race between freeze_process() and refrigerator() in which freeze_process() running on one CPU is reading a task's PF_FREEZE flag while refrigerator() running on another CPU has just set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If the refrigerator wins the race, freeze_process() will state that PF_FREEZE hasn't been set for the task and will set it unnecessarily, so the task will go to the refrigerator once again after it's been thawed. To solve first of these problems we need to stop using PF_FREEZE to tell tasks that they should go to the refrigerator. Instead, we can introduce a special TIF_*** flag and use it for this purpose, since it is allowed to change the other tasks' TIF_*** flags and there are special calls for it. To avoid the freeze_process()-refrigerator() race we can make freeze_process() to always check the task's PF_FROZEN flag after it's read its "freeze" flag. We should also make sure that refrigerator() will always reset the task's "freeze" flag after it's set PF_FROZEN for it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 01:34:30 -07:00
set_tsk_thread_flag(p, TIF_FREEZE);
}
/*
* Sometimes we may need to cancel the previous 'freeze' request
*/
static inline void do_not_freeze(struct task_struct *p)
{
[PATCH] PM: Fix SMP races in the freezer Currently, to tell a task that it should go to the refrigerator, we set the PF_FREEZE flag for it and send a fake signal to it. Unfortunately there are two SMP-related problems with this approach. First, a task running on another CPU may be updating its flags while the freezer attempts to set PF_FREEZE for it and this may leave the task's flags in an inconsistent state. Second, there is a potential race between freeze_process() and refrigerator() in which freeze_process() running on one CPU is reading a task's PF_FREEZE flag while refrigerator() running on another CPU has just set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If the refrigerator wins the race, freeze_process() will state that PF_FREEZE hasn't been set for the task and will set it unnecessarily, so the task will go to the refrigerator once again after it's been thawed. To solve first of these problems we need to stop using PF_FREEZE to tell tasks that they should go to the refrigerator. Instead, we can introduce a special TIF_*** flag and use it for this purpose, since it is allowed to change the other tasks' TIF_*** flags and there are special calls for it. To avoid the freeze_process()-refrigerator() race we can make freeze_process() to always check the task's PF_FROZEN flag after it's read its "freeze" flag. We should also make sure that refrigerator() will always reset the task's "freeze" flag after it's set PF_FROZEN for it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 01:34:30 -07:00
clear_tsk_thread_flag(p, TIF_FREEZE);
}
/*
* Wake up a frozen process
*
* task_lock() is taken to prevent the race with refrigerator() which may
* occur if the freezing of tasks fails. Namely, without the lock, if the
* freezing of tasks failed, thaw_tasks() might have run before a task in
* refrigerator() could call frozen_process(), in which case the task would be
* frozen and no one would thaw it.
*/
static inline int thaw_process(struct task_struct *p)
{
task_lock(p);
if (frozen(p)) {
p->flags &= ~PF_FROZEN;
task_unlock(p);
wake_up_process(p);
return 1;
}
clear_tsk_thread_flag(p, TIF_FREEZE);
task_unlock(p);
return 0;
}
extern void refrigerator(void);
extern int freeze_processes(void);
extern void thaw_processes(void);
static inline int try_to_freeze(void)
{
if (freezing(current)) {
refrigerator();
return 1;
} else
return 0;
}
/*
* The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
* calls wait_for_completion(&vfork) and reset right after it returns from this
* function. Next, the parent should call try_to_freeze() to freeze itself
* appropriately in case the child has exited before the freezing of tasks is
* complete. However, we don't want kernel threads to be frozen in unexpected
* places, so we allow them to block freeze_processes() instead or to set
* PF_NOFREEZE if needed and PF_FREEZER_SKIP is only set for userland vfork
* parents. Fortunately, in the ____call_usermodehelper() case the parent won't
* really block freeze_processes(), since ____call_usermodehelper() (the child)
* does a little before exec/exit and it can't be frozen before waking up the
* parent.
*/
/*
* If the current task is a user space one, tell the freezer not to count it as
* freezable.
*/
static inline void freezer_do_not_count(void)
{
if (current->mm)
current->flags |= PF_FREEZER_SKIP;
}
/*
* If the current task is a user space one, tell the freezer to count it as
* freezable again and try to freeze it.
*/
static inline void freezer_count(void)
{
if (current->mm) {
current->flags &= ~PF_FREEZER_SKIP;
try_to_freeze();
}
}
/*
* Check if the task should be counted as freezeable by the freezer
*/
static inline int freezer_should_skip(struct task_struct *p)
{
return !!(p->flags & PF_FREEZER_SKIP);
}
#else
static inline int frozen(struct task_struct *p) { return 0; }
static inline int freezing(struct task_struct *p) { return 0; }
static inline void freeze(struct task_struct *p) { BUG(); }
static inline int thaw_process(struct task_struct *p) { return 1; }
static inline void refrigerator(void) {}
static inline int freeze_processes(void) { BUG(); return 0; }
static inline void thaw_processes(void) {}
static inline int try_to_freeze(void) { return 0; }
static inline void freezer_do_not_count(void) {}
static inline void freezer_count(void) {}
static inline int freezer_should_skip(struct task_struct *p) { return 0; }
#endif