Re: [PATCH] Fix RCU race in access of nohz_cpu_mask

[Nick Piggin]

David S. Miller wrote:
> From: Andrew Morton <akpm@xxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/