On Mon, Jun 27, 2016 at 12:38 PM, Florian Westphal <f...@strlen.de> wrote:
> Marc Dionne <marc.c.dio...@gmail.com> wrote:
>> On Mon, Jun 27, 2016 at 11:22 AM, Florian Westphal <f...@strlen.de> wrote:
>> > Marc Dionne <marc.c.dio...@gmail.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
iptables
Description: Binary data
ip6tables
Description: Binary data
