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  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:   Wed, 21 Oct 2020 08:18:44 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Benjamin Herrenschmidt' <benh@...nel.crashing.org>,
        Joel Stanley <joel@....id.au>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Dylan Hung <dylan_hung@...eedtech.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>
Subject: RE: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible

From: Benjamin Herrenschmidt
> Sent: 21 October 2020 01:00
> 
> On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote:
> > We must ensure the tx descriptor updates are visible before updating
> > the tx pointer.
> >
> > This resolves the tx hangs observed on the 2600 when running iperf:
> 
> To clarify the comment here. This doesn't ensure they are visible to
> the hardware but to other CPUs. This is the ordering vs start_xmit and
> tx_complete.

You need two barriers.
1) after making the data buffers available before transferring
the descriptor ownership to the device.
2) after transferring the ownership before 'kicking' the mac engine.

The first is needed because the mac engine can poll the descriptors
at any time (eg on completing the previous transmit).
This stops it transmitting garbage.

The second makes sure it finds the descriptor you've just set.
This stops delays before sending the packet.
(But it will get sent later.)

For (2) dma_wmb() is the documented barrier.

I'm not sure which barrier you need for (1).
smp_wmb() would be right if the reader were another cpu,
but it is (at most) a compile barrier on UP kernels.
So you need something stronger than smp_wmb().
On a TSO system (which yours probably is) a compile barrier
is probably sufficient, but if memory writes can get re-ordered
it needs to be a stronger barrier - but not necessarily as strong
as dma_wmb().

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists