On Tue, Mar 27, 2018 at 11:44:22AM +0200, Arnd Bergmann wrote:

On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:

quoted

On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe [off-list ref] wrote:

I'm pretty sure I've never seen
any bug reports pointing to a missing wmb() between memory
and MMIO write accesses, but if you remember seeing them in the
list, maybe you can look again for some evidence of something going
wrong on x86 without it?

The interesting thing is that we do seem to have a whole LOT of these
spurrious wmb before writel all over the tree, I suspect because of
that incorrect recommendation in memory-barriers.txt.

We should fix that.

Maybe the problem is just that it's so counter-intuitive that we don't
need that barrier in Linux, when the hardware does need one on some
architectures.

How about we define a barrier type instruction specifically for this
purpose, something like wmb_before_mmio() and have all architectures
define that to an empty macro?

That way, having correct code using wmb_before_mmio() will not
trigger an incorrect review comment that leads to extra wmb(). ;-)

Please don't add more barriers :)! I think that will make it even more
difficult to understand how to use the ones we already have -- the problem
here seems to be that the documentation that was added for the dma_*
barriers got this wrong, but it was at least in contradiction with the
section elsewhere in memory-barriers.txt that describes the relaxed I/O
accessors.

I guess somebody could hack checkpatch to look for back-to-back wmb/writel
sequences? I suspect we could do something with coccinelle too.

Will