On Tue, Aug 30, 2016 at 06:57:47PM +0200, Oleg Nesterov wrote: > On 08/30, Peter Zijlstra wrote: > > On Tue, Aug 30, 2016 at 03:04:27PM +0200, Oleg Nesterov wrote:
> > > But context switch should imply mb() we can rely on? > > > > Not sure it should, on x86 switch_mm does a CR3 write and that is > > serializing, but switch_to() doesn't need to do anything iirc. > > Documentation/memory-barriers.txt says > > schedule() and similar imply full memory barriers. > > and I (wrongly?) interpreted this as if this is also true for 2 > different threadds. I'm not actually sure it does. There is the comment from 8643cda549ca4 which explain the program order guarantees. But I'm not sure who or what would simply a full smp_mb() when you call schedule() -- I mean, its true on x86, but that's 'trivial'. > I mean, I thought that the LOAD/STORE's done by some task can't > be re-ordered with LOAD/STORE's done by another task which was > running on the same CPU. Wrong? If so, I'm not sure how :/ So smp_mb__before_spinlock() stops stores from @prev, and the ACQUIRE from spin_lock(&rq->lock) stops both loads/stores from @next, but afaict nothing stops the loads from @prev seeing stores from @next. Also not sure this matters though, if they're threads in the same process its a data race already and nobody cares. If they're not threads in the same process, they're separated by address space and can't 'see' each other anyway.
