Re: BUG: iomap_dio_rw() accesses freed memory

[Dave Chinner <david@fromorbit.com>]

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.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com