diff options
author | Andrew Morton <akpm@osdl.org> | 2006-06-30 01:56:00 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-30 11:25:38 -0700 |
commit | e7b384043e27bed4f23b108481b99c518dd01a01 (patch) | |
tree | 52f944bf39d3a7b329f4e38d619d7949e35510a0 /include/linux/rtc.h | |
parent | 92fe15a3d24fa53e7e961c549c488d0bb642d895 (diff) | |
download | talos-obmc-linux-e7b384043e27bed4f23b108481b99c518dd01a01.tar.gz talos-obmc-linux-e7b384043e27bed4f23b108481b99c518dd01a01.zip |
[PATCH] cond_resched() fix
Fix a bug identified by Zou Nan hai <nanhai.zou@intel.com>:
If the system is in state SYSTEM_BOOTING, and need_resched() is true,
cond_resched() returns true even though it didn't reschedule. Consequently
need_resched() remains true and JBD locks up.
Fix that by teaching cond_resched() to only return true if it really did call
schedule().
cond_resched_lock() and cond_resched_softirq() have a problem too. If we're
in SYSTEM_BOOTING state and need_resched() is true, these functions will drop
the lock and will then try to call schedule(), but the SYSTEM_BOOTING state
will prevent schedule() from being called. So on return, need_resched() will
still be true, but cond_resched_lock() has to return 1 to tell the caller that
the lock was dropped. The caller will probably lock up.
Bottom line: if these functions dropped the lock, they _must_ call schedule()
to clear need_resched(). Make it so.
Also, uninline __cond_resched(). It's largeish, and slowpath.
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/linux/rtc.h')
0 files changed, 0 insertions, 0 deletions