Messages in this thread | | | Date | Mon, 12 Dec 2005 15:47:55 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH] Fix RCU race in access of nohz_cpu_mask |
| |
David S. Miller wrote: > From: Andrew Morton <akpm@osdl.org> > Date: Sun, 11 Dec 2005 20:32:26 -0800 > > >>So foo_mb() in preemptible code is potentially buggy. >> >>I guess we assume that a context switch accidentally did enough of the >>right types of barriers for things to work OK. > > > A trap ought to flush all memory operations. > > There are some incredibly difficult memory error handling cases if the > cpu does not synchronize all pending memory operations when a trap > occurs. > > Failing that, yes, to be absolutely safe we'd need to have some > explicit memory barrier in the context switch.
But it isn't that mbs in preemptible code are buggy. If they are scheduled off then back on the same CPU, the barrier will still be executed in the expected instruction sequence for that process.
I think the minimum needed is for cpu *migrations* to be memory barriers. Again, this isn't any particular problem of mb() instructions - if cpu migrations weren't memory barriers, then preemptible code isn't even guaranteed ordering with its own memory operations, which would be quite interesting :)
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |