netdev - Re: [PATCH net-next 0/8] tcp: receiver changes

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]

Message-ID: <d0fea525-5488-48b7-9f88-f6892b5954bf@kernel.org>
Date: Tue, 15 Jul 2025 11:21:35 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
 Neal Cardwell <ncardwell@...gle.com>
Cc: Simon Horman <horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...gle.com>,
 Willem de Bruijn <willemb@...gle.com>, netdev@...r.kernel.org,
 eric.dumazet@...il.com, "David S . Miller" <davem@...emloft.net>,
 Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 0/8] tcp: receiver changes

Hi Paolo,

Thank you for having CCed me!

On 15/07/2025 10:25, Paolo Abeni wrote:
> On 7/11/25 1:39 PM, Eric Dumazet wrote:
>> Before accepting an incoming packet:
>>
>> - Make sure to not accept a packet beyond advertized RWIN.
>>   If not, increment a new SNMP counter (LINUX_MIB_BEYOND_WINDOW)
>>
>> - ooo packets should update rcv_mss and tp->scaling_ratio.
>>
>> - Make sure to not accept packet beyond sk_rcvbuf limit.
>>
>> This series includes three associated packetdrill tests.
> 
> I suspect this series is causing pktdrill failures for the
> tcp_rcv_big_endseq.pkt test case:

(Note that this series introduces this new pktdrill test)

(...)
> the event is happening _before_ the expected time, I guess it's more a
> functional issue than a timing one.
> 
> I also suspect this series is causing flakes in mptcp tests, i.e.:

(...)

> @Matttbe: can you reproduce the flakes locally? if so, does reverting
> that series stop them? (not that I'm planning a revert, just to validate
> my guess).

I'm trying to reproduce this locally on top of net-next, no luck so far.
I will also continue to monitor the MPTCP CI.

For the moment, I don't think it might be linked to this series: NIPA is
validating it since the 11th, and the issues only appeared last night.
Plus, I recently added new MPTCP selftests running these tests in 3
additional modes. If this flake was present for a long time, it might be
more visible today.

Eventually, because the failure is due to a poll timed out, and other
unrelated tests have failed at that time too, could it be due to
overloaded test machines?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.