netdev - Re: [PATCH net-next 0/3] net: ethtool: Track TX pause storm

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: <a1f5c278-99ee-4e99-a6f2-3a50db4ae216@gmail.com>
Date: Fri, 23 Jan 2026 11:31:01 -0800
From: Mohsin Bashir <mohsin.bashr@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, Oleksij Rempel <o.rempel@...gutronix.de>
Cc: netdev@...r.kernel.org, alexanderduyck@...com, alok.a.tiwari@...cle.com,
 andrew+netdev@...n.ch, andrew@...n.ch, chuck.lever@...cle.com,
 davem@...emloft.net, donald.hunter@...il.com, edumazet@...gle.com,
 gal@...dia.com, horms@...nel.org, idosch@...dia.com,
 jacob.e.keller@...el.com, kernel-team@...a.com, kory.maincent@...tlin.com,
 lee@...ger.us, pabeni@...hat.com, vadim.fedorenko@...ux.dev,
 kernel@...gutronix.de, mohsin.bashr@...il.com
Subject: Re: [PATCH net-next 0/3] net: ethtool: Track TX pause storm


> Eh, did you get AI to help write the full version? :) So much text :)
> 
>> - Does the 500ms hardware timer reset on "flapping" pause signals? If so,
>>    a stuttering storm might still crash the link partner (tx watchdog
>>    timeout).
> 
> Yes any discontinuity resets AFAIU, Mohsin keep me honest.
> 

Correct, stuttering resets the timer. A pause storm is only detected 
when we remain continuously in the PAUSE state for more than 500ms.

>> - If main case where we will run in to tx pause storm is OS crash, what
>>    instance will be able to read this stats? Are they preserved on reboot
>>    or kexec?
> 
> Good question! I was wondering the same thing. In the end I couldn't
> figure out which behavior would be less confusing. We want to make sure
> that the stat never increments on a live system, if the machines come
> out of boot with non-zero value some alerting system could fire.
> OTOH as you say we may want to know that it did happen while machine
> was out. So IDK. The fbnic implementation starts with 0.

Right, a non-zero stat would enable monitoring and alerting systems to 
detect anomalies.