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] [day] [month] [year] [list]
Message-ID: <683b4f4779fc490197e4bf48eb6c5a60@AcuMS.aculab.com>
Date:   Thu, 27 Feb 2020 16:00:19 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     David Laight <David.Laight@...LAB.COM>,
        netdev <netdev@...r.kernel.org>
Subject: RE: sys_sendto() spinning for 1.6ms

From: David Laight
> Sent: 27 February 2020 13:19
> 
> I'm looking into unexpected delays in some real time (RTP audio) processing.
> Mostly they are a few 100 usecs in the softint code.
> 
> However I've just triggered in sendto() on a raw IPV4 socket taking 1.6ms.
> Most of the sends take less than 32us.
...
> Cpu 2 trace is:
>     pid-28219 [002] .... 1979891.159912: sys_sendto(fd: 394, buff: 7ffbcb2e2940, len: c8, flags: 0,
> addr: 7ffbccdc9490, addr_len: 10)
>     pid-28219 [002] .... 1979891.161647: sys_sendto -> 0xc8
> 

Ok, I've found the buggy piece of crap responsible:

1992857.294910 |   2)  Prosody-5812  |               |  raw_sendmsg() {
1992857.294912 |   2)  Prosody-5812  |   1.099 us    |    __ew32_prepare [e1000e]();
1992857.294913 |   2)  Prosody-5812  |   0.855 us    |    __ew32_prepare [e1000e]();
1992857.294915 |   2)  Prosody-5812  |   0.773 us    |    __ew32_prepare [e1000e]();
1992857.294916 |   2)  Prosody-5812  | ! 202.689 us  |    __ew32_prepare [e1000e]();
1992857.295155 |   2)  Prosody-5812  | ! 253.162 us  |    __ew32_prepare [e1000e]();
1992857.295409 |   2)  Prosody-5812  |   0.855 us    |    __ew32_prepare [e1000e]();
1992857.295411 |   2)  Prosody-5812  | ! 500.828 us  |  }

/**
 * __ew32_prepare - prepare to write to MAC CSR register on certain parts
 * @hw: pointer to the HW structure
 *
 * When updating the MAC CSR registers, the Manageability Engine (ME) could
 * be accessing the registers at the same time.  Normally, this is handled in
 * h/w by an arbiter but on some parts there is a bug that acknowledges Host
 * accesses later than it should which could result in the register to have
 * an incorrect value.  Workaround this by checking the FWSM register which
 * has bit 24 set while ME is accessing MAC CSR registers, wait if it is set
 * and try again a number of times.
 **/
s32 __ew32_prepare(struct e1000_hw *hw)
{
        s32 i = E1000_ICH_FWSM_PCIM2PCI_COUNT; // 2000

        while ((er32(FWSM) & E1000_ICH_FWSM_PCIM2PCI) && --i)
                udelay(50);

        return i;
}

WTF!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

That it just so broken....

Notwithstanding anything else the bit can get set just after
we've checked it isn't set.
So the code doesn't solve anything at all.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ