Messages in this thread | | | Date | Mon, 6 Aug 2007 09:30:40 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] pi-futex: set PF_EXITING without taking ->pi_lock |
| |
* Oleg Nesterov <oleg@tv-sign.ru> wrote:
> Question: should we make spinlock_t barrier-safe? > > Suppose that the task "p" does > > current->state = TASK_INTERRUPIBLE; > mb(); > > if (CONDITION) > break; > > schedule(); > > and another CPU does > > CONDITION = 1; > try_to_wake_up(p); > > > This is commonly used, but not correct _in theory_. If wake_up() happens > when p->array != NULL, we have > > CONDITION = 1; // [1] > spin_lock(rq->lock); > task->state = TASK_RUNNING; // [2] > > and we can miss an event. Because in theory [1] may leak into the critical > section, and could be re-ordered with [2]. > > Another problem is that try_to_wake_up() first checks task->state and does > nothing if it is TASK_RUNNING, so we need a full mb(), not just wmb(). > > Should we change spin_lock(), or introduce smp_mb_before_spinlock(), or I > missed something? > > NOTE: I do not pretend to know what kind of barrier spin_lock() provides > in practice, but according to the documentation lock() is only a one-way > barrier.
i think your worry is legitimate.
spin_lock() provides a full barrier on most platforms (certainly so on x86). But ... ia64 might have it as a one-way barrier?
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |