netdev - Re: [PATCH net-next] selftests/net: packetdrill: make tcp buf limited timing tests benign

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: <16f25267-059c-4792-9928-a868ac3ee309@kernel.org>
Date: Fri, 17 Jan 2025 12:21:17 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 andrew+netdev@...n.ch, horms@...nel.org, shuah@...nel.org,
 willemb@...gle.com, linux-kselftest@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH net-next] selftests/net: packetdrill: make tcp buf limited
 timing tests benign

Hi Willem, Jakub,

On 16/01/2025 14:05, Willem de Bruijn wrote:
> Jakub Kicinski wrote:
>> The following tests are failing on debug kernels:
>>
>>   tcp_tcp_info_tcp-info-rwnd-limited.pkt
>>   tcp_tcp_info_tcp-info-sndbuf-limited.pkt

(...)

> We'll take a look after this change whether we can make these
> more resilient. But likely also allow-list or even xfail for
> everything in dbg.

On MPTCP side, I spent quite a bit of time trying to improve the
situation on debug kernels. Sure it feels good and reassuring to have
spent this time understanding the instabilities. Most issues were due to
spurious retransmissions, because Packetdrill was "too slow" to inject
replies: so more like an issue in the tests. But I don't know if having
these tests running in such slow environments helped to find bugs
directly, e.g. catching unexpected packets. Maybe once? But at what cost?

Still it is good to run them on debug kernels to have extra
verifications on the kernel side. As Ido mentioned last summer, perhaps
we can ignore the test results, but keep logging them, and only look at
the kernel warnings?

So yes, I agree with Willem: if that cannot easily be fixed, ignoring
packetdrill err code for everything in debug sounds like the right
direction.

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