lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 29 Mar 2018 02:23:24 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     benh@...nel.crashing.org, paulmck@...ux.vnet.ibm.com,
        arnd@...db.de, linux-rdma@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linus971@...il.com,
        will.deacon@....com, alexander.duyck@...il.com,
        okaya@...eaurora.org, jgg@...pe.ca, David.Laight@...lab.com,
        oohall@...il.com, netdev@...r.kernel.org,
        alexander.h.duyck@...hat.com, torvalds@...ux-foundation.org
Subject: Re: RFC on writel and writel_relaxed

On Wed, 28 Mar 2018 11:55:09 -0400 (EDT)
David Miller <davem@...emloft.net> wrote:

> From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Date: Thu, 29 Mar 2018 02:13:16 +1100
> 
> > Let's fix all archs, it's way easier than fixing all drivers. Half of
> > the archs are unused or dead anyway.  
> 
> Agreed.

While we're making decrees here, can we do something about mmiowb?
The semantics are basically indecipherable.

  This is a variation on the mandatory write barrier that causes writes to weakly
  ordered I/O regions to be partially ordered.  Its effects may go beyond the
  CPU->Hardware interface and actually affect the hardware at some level.

How can a driver writer possibly get that right?

IIRC it was added for some big ia64 system that was really expensive
to implement the proper wmb() semantics on. So wmb() semantics were
quietly downgraded, then the subsequently broken drivers they cared
about were fixed by adding the stronger mmiowb().

What should have happened was wmb and writel remained correct, sane, and
expensive, and they add an mmio_wmb() to order MMIO stores made by the
writel_relaxed accessors, then use that to speed up the few drivers they
care about.

Now that ia64 doesn't matter too much, can we deprecate mmiowb and just
make wmb ordering talk about stores to the device, not to some
intermediate stage of the interconnect where it can be subsequently
reordered wrt the device? Drivers can be converted back to using wmb
or writel gradually.

Thanks,
Nick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ