netdev - Re: WARNING in tcp_update

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

Message-ID: <7a626cf6-e1c4-ea17-c790-a6901383b1b1@gmail.com>
Date:   Mon, 16 Oct 2017 19:00:39 -0600
From:   David Ahern <dsahern@...il.com>
To:     Yuchung Cheng <ycheng@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrei Vagin <avagin@...il.com>
Subject: Re: WARNING in tcp_update_reordering

[ cc Andrei who reported a similar trace ]

On 10/16/17 6:50 PM, Yuchung Cheng wrote:
> On Mon, Oct 16, 2017 at 3:38 PM, David Ahern <dsahern@...il.com> wrote:
>> I need to throw this one over the fence. I triggered the trace below
>> testing changes to the tcp tracepoint. It is not readily reproducible
>> and does not appear to be correlated to the perf session.
> We're seeing this internally at Google a lot as well. The culprit is
> because TCP tries to measure/track reordering in precise packet
> distance (tp->reordering). That's difficult but also fairly useless to
> get right because that highly depends on the instantaneous
> traffic load and L2/pathing behavior. In other words the previous
> reordering degree has little bearing for my next reordering based on
> our analysis. The
> warning itself has minor to no impact on TCP performance or
> reliability.
> 
> I am testing a patch to replace that approach (and remove the
> warning). Should be ready soon.
> 

Thanks for the update.