On 2017-06-22 19:30:07 [+0200], Mike Galbraith wrote: > On Thu, 2017-06-22 at 18:34 +0200, Sebastian Andrzej Siewior wrote: > > On 2017-06-20 09:45:06 [+0200], Mike Galbraith wrote: > > > See ! and ? > > > > See see. > > What about this: > > I'll give it a go, likely during the weekend. It survived >1d on my AMD-A10 box. I am adding this description: |If a task is queued as a sleeper for a wakeup and never goes to |schedule() (because it just obtained the lock) then it will receive a |spurious wake up which is not "bad", it is considered. Until that wake |up happens this task can no be enqueued for any wake ups handled by the |WAKE_Q infrastructure (because a task can only be enqueued once). This |wouldn't be bad if we would use the same wakeup mechanism for the wake |up of sleepers as we do for "normal" wake ups. But we don't… | |So. | T1 T2 T3 | spin_lock(x) spin_unlock(x); | wake_q_add(q1, T1) | spin_unlock(x) | set_state(TASK_INTERRUPTIBLE) | if (!condition) | schedule() | condition = true | wake_q_add(q2, T1) | // T1 not added, still enqueued | wake_up_q(q2) | wake_up_q_sleeper(q1) | // T1 not woken up, wrong task state | |In order to solve this race this patch adds a wake_q_node for the |sleeper case. and consider this closed unless I hear from you different things :) Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
