netdev - Re: [TEST] txtimestamp.sh pains after netdev foundation migration

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: <20260107192511.23d8e404@kernel.org>
Date: Wed, 7 Jan 2026 19:25:11 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Willem de Bruijn <willemb@...gle.com>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>
Subject: Re: [TEST] txtimestamp.sh pains after netdev foundation migration

Thanks for investigating!

On Wed, 07 Jan 2026 19:19:53 -0500 Willem de Bruijn wrote:
> 17 out of 20 happen in the first SND-USR calculation.
> One representative example:
> 
>     # 7.11 [+0.00] test SND
>     # 7.11 [+0.00]     USR: 1767443466 s 155019 us (seq=0, len=0)
>     # 7.19 [+0.08] ERROR: 18600 us expected between 10000 and 18000
>     # 7.19 [+0.00]     SND: 1767443466 s 173619 us (seq=0, len=10)  (USR +18599 us)
>     # 7.20 [+0.00]     USR: 1767443466 s 243683 us (seq=0, len=0)
>     # 7.27 [+0.07]     SND: 1767443466 s 253690 us (seq=1, len=10)  (USR +10006 us)
>     # 7.27 [+0.00]     USR: 1767443466 s 323746 us (seq=0, len=0)
>     # 7.35 [+0.08]     SND: 1767443466 s 333752 us (seq=2, len=10)  (USR +10006 us)
>     # 7.35 [+0.00]     USR: 1767443466 s 403811 us (seq=0, len=0)
>     # 7.43 [+0.08]     SND: 1767443466 s 413817 us (seq=3, len=10)  (USR +10006 us)
>     # 7.43 [+0.00]     USR-SND: count=4, avg=12154 us, min=10006 us, max=18599 us

Hm, that's the first kernel timestamp vs the timestamp in user space?
I wonder if we could catch this by re-taking the user stamp after
sendmsg() returns, if >1msec elapsed something is probably wrong 
(we got scheduled out before having a chance to complete the send?)

> These are just outside the bounds of 18000. So increasing the
> tolerance in txtimestamp.sh will probably mitigate them. All 17
> would have passed with the following change.
> 
> -        local -r args="$@ -v 10000 -V 60000 -t 8000 -S 80000"
> +        local -r args="$@ -v 10000 -V 60000 -t 8000 -S 100000"
> 
> Admittedly a hacky workaround that will only reduce the rate.
> 
> It's interesting that
> 
> - every time it is the first of the four measurements that fails.
> - it never seems to occur for TCP sockets.

FWIW:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net/results/449080/13-txtimestamp-sh/stdout
but that could be related to some bad patch..