diff options
author | Peter Zijlstra <peterz@infradead.org> | 2018-04-30 14:50:22 +0200 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2018-05-03 07:38:04 +0200 |
commit | 741a76b350897604c48fb12beff1c9b77724dc96 (patch) | |
tree | 2f2a010fb227f8c14853ab8bd5e17697d92054db /block/blk-softirq.c | |
parent | 457be908c83637ee10bda085a23dc05afa3b14a0 (diff) | |
download | linux-741a76b350897604c48fb12beff1c9b77724dc96.tar.bz2 |
kthread, sched/wait: Fix kthread_parkme() wait-loop
Gaurav reported a problem with __kthread_parkme() where a concurrent
try_to_wake_up() could result in competing stores to ->state which,
when the TASK_PARKED store got lost bad things would happen.
The comment near set_current_state() actually mentions this competing
store, but only mentions the case against TASK_RUNNING. This same
store, with different timing, can happen against a subsequent !RUNNING
store.
This normally is not a problem, because as per that same comment, the
!RUNNING state store is inside a condition based wait-loop:
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (!need_sleep)
break;
schedule();
}
__set_current_state(TASK_RUNNING);
If we loose the (first) TASK_UNINTERRUPTIBLE store to a previous
(concurrent) wakeup, the schedule() will NO-OP and we'll go around the
loop once more.
The problem here is that the TASK_PARKED store is not inside the
KTHREAD_SHOULD_PARK condition wait-loop.
There is a genuine issue with sleeps that do not have a condition;
this is addressed in a subsequent patch.
Reported-by: Gaurav Kohli <gkohli@codeaurora.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'block/blk-softirq.c')
0 files changed, 0 insertions, 0 deletions