On Wed, Jan 16, 2019 at 10:18:51AM +1100, Dave Chinner wrote: > On Tue, Jan 15, 2019 at 10:09:03PM +0100, Christoph Hellwig wrote: > > On Wed, Jan 16, 2019 at 07:51:41AM +1100, Dave Chinner wrote: > > > Atomic operations don't imply a memory barrier for dependent data, > > > right? > > > > Documentation/atomic_t.txt says: > > > > -------------------------- snip -------------------------- > > The rule of thumb: > > > > - non-RMW operations are unordered; > > > > - RMW operations that have no return value are unordered; > > > > - RMW operations that have a return value are fully ordered; > > > > [...] > > > > Fully ordered primitives are ordered against everything prior and everything > > subsequent. Therefore a fully ordered primitive is like having an smp_mb() > > before and an smp_mb() after the primitive. > > I guess I haven't looked at the documentation for a while. Or the > implementation for that matter. > > /me goes off and looks. > > Oh, they are now implemented with built in, explicit > smp_mb__before_atomic() and smp_mb__after_atomic() barriers. Ok, > so the necessary barriers are there, my brain was telling me they > still needed to be added manually and needed updating..... FWIW this fixes the machine that was cranking out generic/323 hangs, having run it repeatedly in a loop for the ~4 hours in between falling down the stairs this morning and finally getting back from all the errands I had to do today. Ready for this crap year to be over with, which means this ought to have someone other than me look over it: Tested-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
