netdev - Re: [RFC PATCH] net: don't keep lonely packets forever in the gro hash

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: <6422ed19-13cf-ffe1-dbe1-984041779800@iogearbox.net>
Date:   Wed, 21 Nov 2018 10:13:45 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>,
        alexei.starovoitov@...il.com, brakmo@...com
Subject: Re: [RFC PATCH] net: don't keep lonely packets forever in the gro
 hash

Hi Eric,

On 11/20/2018 02:49 PM, Eric Dumazet wrote:
> On 11/20/2018 02:17 AM, Paolo Abeni wrote:
>> Eric noted that with UDP GRO and napi timeout, we could keep a single
>> UDP packet inside the GRO hash forever, if the related NAPI instance
>> calls napi_gro_complete() at an higher frequency than the napi timeout.
>> Willem noted that even TCP packets could be trapped there, till the
>> next retransmission.
>> This patch tries to address the issue, flushing the oldest packets before
>> scheduling the NAPI timeout. The rationale is that such a timeout should be
>> well below a jiffy and we are not flushing packets eligible for sane GRO.
>>
>> Reported-by: Eric Dumazet <eric.dumazet@...il.com>
>> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
>> ---
>> Sending as RFC, as I fear I'm missing some relevant pieces.
>> Also I'm unsure if this should considered a fixes for "udp: implement
>> GRO for plain UDP sockets." or for "net: gro: add a per device gro flush timer"
> 
> You can add both, now worries.
> 
> Google DC TCP forces a PSH flag on all TSO packets, so for us the flush is done
> because of the PSH flag, not upon a timer/jiffie.

Any plans to upstream this change? Or is the concern that this should only
be used DC internally? (If the latter, perhaps it would make sense to add
this under DCTCP mode then?)

Thanks a lot,
Daniel