netdev - Multi-thread udp 4.7 regression, bisected to 71d8c47fc653

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-next>] [day] [month] [year] [list]

Date:	Mon, 27 Jun 2016 10:41:49 -0300
From:	Marc Dionne <marc.c.dionne@...il.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>,
	netdev <netdev@...r.kernel.org>
Subject: Multi-thread udp 4.7 regression, bisected to 71d8c47fc653

Hi,

I've been seeing issues with 4.7-rc kernels with some of our
multi-thread test cases.  I've bisected it down to this commit:

  commit 71d8c47fc653711c41bc3282e5b0e605b3727956
  Author: Pablo Neira Ayuso <pablo@...filter.org>
  Date:   Sun May 1 00:28:40 2016 +0200

      netfilter: conntrack: introduce clash resolution on insertion race

.. and verified that reverting the commit restores the expected behaviour.

The test spins up 30 threads that start communicating simultaneously
with a server at the same target port, using a UDP based protocol over
loopback.  This test is known to easily trigger the insertion race
that the commit is trying to fix - we check for EPERM errors and retry
in that case.

On my usual test rig the test gets about 700Mb/s.  On current
mainline, the result alternates between a somewhat normal number,
something much lower (~150Mb/s), or complete failure following an
internal timeout.

Any thoughts on what may be going on?

Thanks,
Marc