On Tue, Jan 29, 2019 at 10:18:20AM -0800, Suren Baghdasaryan wrote: > On Tue, Jan 29, 2019 at 4:38 AM Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Thu, Jan 24, 2019 at 01:15:18PM -0800, Suren Baghdasaryan wrote: > > > + atomic_set(&group->polling, polling); > > > + /* > > > + * Memory barrier is needed to order group->polling > > > + * write before times[] read in > > > collect_percpu_times() > > > + */ > > > + smp_mb__after_atomic(); > > > > That's broken, smp_mb__{before,after}_atomic() can only be used on > > atomic RmW operations, something atomic_set() is _not_. > > Oh, I didn't realize that. After reading the following example from > atomic_ops.txt
That document it woefully out of date (and I should double check, but I think we can actually delete it now). Please see Documentation/atomic_t.txt > I was under impression that smp_mb__after_atomic() > would make changes done by atomic_set() visible: > > /* All memory operations before this call will > * be globally visible before the clear_bit(). > */ > smp_mb__before_atomic(); > clear_bit( ... ); > /* The clear_bit() will be visible before all > * subsequent memory operations. > */ > smp_mb__after_atomic(); > > but I'm probably missing something. Is there a more detailed > description of these rules anywhere else? See atomic_t.txt; but the difference is that clear_bit() is a RmW, while atomic_set() is just a plain store. > Meanwhile I'll change smp_mb__after_atomic() into smp_mb(). Would that > fix the ordering? It would work here; but I'm still trying to actually understand all this. So while the detail would be fine, I'm not ready to judge the over-all thing.