linux-kernel - RE: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible

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 for Android: free password hash cracker in your pocket

[<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)