kernel-ark/include/linux/freezer.h

187 lines
4.9 KiB
C
Raw Normal View History

/* Freezer declarations */
#ifndef FREEZER_H_INCLUDED
#define FREEZER_H_INCLUDED
[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 10:18:58 +00:00
#include <linux/sched.h>
#include <linux/wait.h>
[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 10:18:58 +00:00
#ifdef CONFIG_PM_SLEEP
/*
* 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 08:34:30 +00:00
return test_tsk_thread_flag(p, TIF_FREEZE);
}
/*
* Request that a process be frozen
*/
Freezer: avoid freezing kernel threads prematurely Kernel threads should not have TIF_FREEZE set when user space processes are being frozen, since otherwise some of them might be frozen prematurely. To prevent this from happening we can (1) make exit_mm() unset TIF_FREEZE unconditionally just after clearing tsk->mm and (2) make try_to_freeze_tasks() check if p->mm is different from zero and PF_BORROWED_MM is unset in p->flags when user space processes are to be frozen. Namely, when user space processes are being frozen, we only should set TIF_FREEZE for tasks that have p->mm different from NULL and don't have PF_BORROWED_MM set in p->flags. For this reason task_lock() must be used to prevent try_to_freeze_tasks() from racing with use_mm()/unuse_mm(), in which p->mm and p->flags.PF_BORROWED_MM are changed under task_lock(p). Also, we need to prevent the following scenario from happening: * daemonize() is called by a task spawned from a user space code path * freezer checks if the task has p->mm set and the result is positive * task enters exit_mm() and clears its TIF_FREEZE * freezer sets TIF_FREEZE for the task * task calls try_to_freeze() and goes to the refrigerator, which is wrong at that point This requires us to acquire task_lock(p) before p->flags.PF_BORROWED_MM and p->mm are examined and release it after TIF_FREEZE is set for p (or it turns out that TIF_FREEZE should not be set). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@nigel.suspend2.net> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 08:47:33 +00:00
static inline void set_freeze_flag(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 08:34:30 +00:00
set_tsk_thread_flag(p, TIF_FREEZE);
}
/*
* Sometimes we may need to cancel the previous 'freeze' request
*/
Freezer: avoid freezing kernel threads prematurely Kernel threads should not have TIF_FREEZE set when user space processes are being frozen, since otherwise some of them might be frozen prematurely. To prevent this from happening we can (1) make exit_mm() unset TIF_FREEZE unconditionally just after clearing tsk->mm and (2) make try_to_freeze_tasks() check if p->mm is different from zero and PF_BORROWED_MM is unset in p->flags when user space processes are to be frozen. Namely, when user space processes are being frozen, we only should set TIF_FREEZE for tasks that have p->mm different from NULL and don't have PF_BORROWED_MM set in p->flags. For this reason task_lock() must be used to prevent try_to_freeze_tasks() from racing with use_mm()/unuse_mm(), in which p->mm and p->flags.PF_BORROWED_MM are changed under task_lock(p). Also, we need to prevent the following scenario from happening: * daemonize() is called by a task spawned from a user space code path * freezer checks if the task has p->mm set and the result is positive * task enters exit_mm() and clears its TIF_FREEZE * freezer sets TIF_FREEZE for the task * task calls try_to_freeze() and goes to the refrigerator, which is wrong at that point This requires us to acquire task_lock(p) before p->flags.PF_BORROWED_MM and p->mm are examined and release it after TIF_FREEZE is set for p (or it turns out that TIF_FREEZE should not be set). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@nigel.suspend2.net> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 08:47:33 +00:00
static inline void clear_freeze_flag(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 08:34:30 +00: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;
}
Freezer: avoid freezing kernel threads prematurely Kernel threads should not have TIF_FREEZE set when user space processes are being frozen, since otherwise some of them might be frozen prematurely. To prevent this from happening we can (1) make exit_mm() unset TIF_FREEZE unconditionally just after clearing tsk->mm and (2) make try_to_freeze_tasks() check if p->mm is different from zero and PF_BORROWED_MM is unset in p->flags when user space processes are to be frozen. Namely, when user space processes are being frozen, we only should set TIF_FREEZE for tasks that have p->mm different from NULL and don't have PF_BORROWED_MM set in p->flags. For this reason task_lock() must be used to prevent try_to_freeze_tasks() from racing with use_mm()/unuse_mm(), in which p->mm and p->flags.PF_BORROWED_MM are changed under task_lock(p). Also, we need to prevent the following scenario from happening: * daemonize() is called by a task spawned from a user space code path * freezer checks if the task has p->mm set and the result is positive * task enters exit_mm() and clears its TIF_FREEZE * freezer sets TIF_FREEZE for the task * task calls try_to_freeze() and goes to the refrigerator, which is wrong at that point This requires us to acquire task_lock(p) before p->flags.PF_BORROWED_MM and p->mm are examined and release it after TIF_FREEZE is set for p (or it turns out that TIF_FREEZE should not be set). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@nigel.suspend2.net> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 08:47:33 +00:00
clear_freeze_flag(p);
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);
}
/*
* Tell the freezer that the current task should be frozen by it
*/
static inline void set_freezable(void)
{
current->flags &= ~PF_NOFREEZE;
}
/*
* Freezer-friendly wrappers around wait_event_interruptible() and
* wait_event_interruptible_timeout(), originally defined in <linux/wait.h>
*/
#define wait_event_freezable(wq, condition) \
({ \
int __retval; \
do { \
__retval = wait_event_interruptible(wq, \
(condition) || freezing(current)); \
if (__retval && !freezing(current)) \
break; \
else if (!(condition)) \
__retval = -ERESTARTSYS; \
} while (try_to_freeze()); \
__retval; \
})
#define wait_event_freezable_timeout(wq, condition, timeout) \
({ \
long __retval = timeout; \
do { \
__retval = wait_event_interruptible_timeout(wq, \
(condition) || freezing(current), \
__retval); \
} while (try_to_freeze()); \
__retval; \
})
#else /* !CONFIG_PM_SLEEP */
static inline int frozen(struct task_struct *p) { return 0; }
static inline int freezing(struct task_struct *p) { return 0; }
Freezer: avoid freezing kernel threads prematurely Kernel threads should not have TIF_FREEZE set when user space processes are being frozen, since otherwise some of them might be frozen prematurely. To prevent this from happening we can (1) make exit_mm() unset TIF_FREEZE unconditionally just after clearing tsk->mm and (2) make try_to_freeze_tasks() check if p->mm is different from zero and PF_BORROWED_MM is unset in p->flags when user space processes are to be frozen. Namely, when user space processes are being frozen, we only should set TIF_FREEZE for tasks that have p->mm different from NULL and don't have PF_BORROWED_MM set in p->flags. For this reason task_lock() must be used to prevent try_to_freeze_tasks() from racing with use_mm()/unuse_mm(), in which p->mm and p->flags.PF_BORROWED_MM are changed under task_lock(p). Also, we need to prevent the following scenario from happening: * daemonize() is called by a task spawned from a user space code path * freezer checks if the task has p->mm set and the result is positive * task enters exit_mm() and clears its TIF_FREEZE * freezer sets TIF_FREEZE for the task * task calls try_to_freeze() and goes to the refrigerator, which is wrong at that point This requires us to acquire task_lock(p) before p->flags.PF_BORROWED_MM and p->mm are examined and release it after TIF_FREEZE is set for p (or it turns out that TIF_FREEZE should not be set). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@nigel.suspend2.net> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 08:47:33 +00:00
static inline void set_freeze_flag(struct task_struct *p) {}
static inline void clear_freeze_flag(struct task_struct *p) {}
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; }
static inline void set_freezable(void) {}
#define wait_event_freezable(wq, condition) \
wait_event_interruptible(wq, condition)
#define wait_event_freezable_timeout(wq, condition, timeout) \
wait_event_interruptible_timeout(wq, condition, timeout)
#endif /* !CONFIG_PM_SLEEP */
#endif /* FREEZER_H_INCLUDED */