Messages in this thread Patch in this message | | | Date | Wed, 24 Sep 2014 10:18:46 +0200 | From | Peter Zijlstra <> | Subject | [PATCH 01/11] locking/mutex: Dont assume TASK_RUNNING |
| |
We're going to make might_sleep() test for TASK_RUNNING, because blocking without TASK_RUNNING will destroy the task state by setting it to TASK_RUNNING.
There are a few occasions where its 'valid' to call blocking primitives (and mutex_lock in particular) and not have TASK_RUNNING, typically such cases are right before we set TASK_RUNNING anyhow.
Robustify the code by not assuming this; this has the beneficial side effect of allowing optional code emission for fixing the above might_sleep() false positives.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- kernel/locking/mutex.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
--- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -378,8 +378,14 @@ static bool mutex_optimistic_spin(struct * reschedule now, before we try-lock the mutex. This avoids getting * scheduled out right after we obtained the mutex. */ - if (need_resched()) + if (need_resched()) { + /* + * We _should_ have TASK_RUNNING here, but just in case + * we do not, make it so, otherwise we might get stuck. + */ + __set_current_state(TASK_RUNNING); schedule_preempt_disabled(); + } return false; }
| |