On Sat, 23 Feb 2008, Dmitry Adamushko wrote: > > it's not a LOAD that escapes *out* of the region. It's a MODIFY that gets *in*: Not with the smp_wmb(). That's the whole point. Ie the patch I'm suggesting is sufficient is appended, and the point is that any write before the critical region will be ordered wrt the critical region because of the write barrier before the spinlock (which itself is a write). This is also why I mentioned that if you have a really odd architecure that considers spinlocks to be "outside" the normal cache coherency domain, that would be broken, but I cannot think of a single valid case of that, and I consider it insane. (There are supecomputers that have a separate "barrier" network that can be used to do global ordering, but they don't generally do cache coherency and dependable memory ordering at all, which is why they need the separate barrier network in the first place. So that odd case isn't relevant to this discussion, even if it's historically interesting ;^) But I'd love to hear a good argument why this wouldn't work on some architecture that we actually support (or might want to support in the future).. Memory ordering is interesting (even if the only people who do it right is Intel and AMD). Linus --- kernel/sched.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index f28f19e..3bceb3b 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -1831,6 +1831,7 @@ static int try_to_wake_up(struct task_struct *p, unsigned int state, int sync) long old_state; struct rq *rq; + smp_wmb(); rq = task_rq_lock(p, &flags); old_state = p->state; if (!(old_state & state)) - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
