netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Jun 2016 14:21:15 -0300
From:	Marc Dionne <marc.c.dionne@...il.com>
To:	Florian Westphal <fw@...len.de>
Cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Multi-thread udp 4.7 regression, bisected to 71d8c47fc653

On Mon, Jun 27, 2016 at 12:38 PM, Florian Westphal <fw@...len.de> wrote:
> Marc Dionne <marc.c.dionne@...il.com> wrote:
>> On Mon, Jun 27, 2016 at 11:22 AM, Florian Westphal <fw@...len.de> wrote:
>> > Marc Dionne <marc.c.dionne@...il.com> wrote:
>> >> Hi,
>
>> >         hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[hash], hnnode)
>> >                 if (nf_ct_key_equal(h, &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
>> > -                                   zone, net))
>> > -                       goto out;
>> > +                                   zone, net)) {
>> > +                       nf_ct_add_to_dying_list(ct);
>> > +                       ret = nf_ct_resolve_clash(net, skb, ctinfo, h);
>> > +                       goto dying;
>> > +               }
>
> This is bogus as h can be a reply too (key compare does not deal
> with it).
>
> Below is what I actually intended; I can't come up with a reason why
> you experience this issue other than that we're getting confused over
> reply/original direction.
>
> If the patch doesn't help either, can you tell us what kind of iptables
> rules are installed on the affected system or perhaps report perf drop
> monitor stat when things go wrong?
>
> Thanks!

The additional patch didn't help either.

I had a lot of iptables bloat, but I reverted to old simple iptables
and ip6tables configs (attached), and still see the problem.  Note
that the test normally uses ipv6, but the behaviour is the same with
ipv4.

Marc

Download attachment "iptables" of type "application/octet-stream" (550 bytes)

Download attachment "ip6tables" of type "application/octet-stream" (969 bytes)