netdev - Re: [PATCH net-next v2 0/3] selftests/net: packetdrill: netns and two imports

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: <66e2da1b440cc_14a89129431@willemb.c.googlers.com.notmuch>
Date: Thu, 12 Sep 2024 08:10:03 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Matthieu Baerts <matttbe@...nel.org>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 netdev@...r.kernel.org
Cc: davem@...emloft.net, 
 kuba@...nel.org, 
 edumazet@...gle.com, 
 pabeni@...hat.com, 
 ncardwell@...gle.com, 
 shuah@...nel.org, 
 linux-kselftest@...r.kernel.org, 
 Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next v2 0/3] selftests/net: packetdrill: netns and two
 imports

Matthieu Baerts wrote:
> Hi Willem,
> 
> On 12/09/2024 02:52, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@...gle.com>
> > 
> > 1/3: run in nets, as discussed, and add missing CONFIGs
> > 2/3: import tcp/zerocopy
> > 3/3: import tcp/slow_start
> 
> Thank you for the v2. This new version looks good to me:
> 
> Acked-by: Matthieu Baerts (NGI0) <matttbe@...nel.org>
> 
> 
> I didn't pay too much attention to the new tests, because they look
> good, heavily tested I suppose, and I guess the goal is not to diverge
> from the original ones for the moment. Still, please note that the CI
> reported some timing issues with tcp_zerocopy_closed.pkt when using a
> debug kernel config, e.g.
> 
> > tcp_zerocopy_closed.pkt:22: timing error: expected system call return at 0.100596 sec but happened at 0.109564 sec; tolerance 0.004000 sec
> 
> https://netdev.bots.linux.dev/contest.html?executor=vmksft-packetdrill-dbg&test=tcp-zerocopy-closed-pkt

Thanks Matthieu. I did not run the dbg variant often enough to observe
that. Note to self to run more times before I submit.

It seems to fail 2/10 times on the dbg spinner. I don't have an
explanation for the failure yet. The line itself has no expected delay

# script packet:  0.113203 S 0:0(0) <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8>
# actual packet:  0.107191 S 0:0(0) win 65535 <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8>

   +0.1 recvmsg(4, {msg_name(...)=...,
                    msg_iov(1)=[{...,0}],
                    msg_flags=MSG_ERRQUEUE,
                    msg_control=[]}, MSG_ERRQUEUE) = -1 EAGAIN (Resource temporarily unavailable)

   +0...0 connect(4, ..., ...) = 0

   +0 > S 0:0(0) <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8>

I guess the expectation includes the +0.1 delay before calling recvmsg, and that
timer fired a bit early.

I previously shared a draft patch to adjust --tolerance_usecs in dbg runs.
May have to send that after all.

https://lore.kernel.org/netdev/66da5b8b27259_27bb41294c@willemb.c.googlers.com.notmuch/