netdev - Re: Tulip 21142 panic on physical link disconnect

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: <alpine.DEB.2.21.2506192238280.37405@angie.orcam.me.uk>
Date: Thu, 19 Jun 2025 22:53:51 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Florian Fainelli <f.fainelli@...il.com>
cc: Greg Chandler <chandleg@...ardsworks.org>, stable@...r.kernel.org, 
    netdev@...r.kernel.org
Subject: Re: Tulip 21142 panic on physical link disconnect

On Thu, 19 Jun 2025, Florian Fainelli wrote:

> >   Maybe it'll ring someone's bell and they'll chime in or otherwise I'll
> > bisect it... sometime.  Or feel free to start yourself with 5.18, as it's
> > not terribly old, only a bit and certainly not so as 2.6 is.
> 
> I am still not sure why I could not see that warning on by Cobalt Qube2 trying
> to reproduce Greg's original issue, that is with an IP assigned on the
> interface yanking the cable did not trigger a timer warning. It could be that
> machine is orders of magnitude slower and has a different CONFIG_HZ value that
> just made it less likely to be seen?

 Can it have a different PHY attached?  There's this code:

	if (tp->chip_id == PNIC2)
		tp->link_change = pnic2_lnk_change;
	else if (tp->flags & HAS_NWAY)
		tp->link_change = t21142_lnk_change;
	else if (tp->flags & HAS_PNICNWAY)
		tp->link_change = pnic_lnk_change;

in `tulip_init_one' and `pnic_lnk_change' won't ever trigger this, but the 
other two can; apparently the corresponding comment in `tulip_interrupt':
                        
/*                        
 * NB: t21142_lnk_change() does a del_timer_sync(), so be careful if this
 * call is ever done under the spinlock
 */

hasn't been updated when `pnic2_lnk_change' was added.  Also ISTM no link 
change handler is a valid option too, in which case `del_timer_sync' won't 
be called either.  This is from a cursory glance only, so please take with 
a pinch of salt.

  Maciej