netdev - Re: [PATCH] Revert "net: phy: turn carrier off on phy attach"

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: <20160212210728.GA5454@archie.tuxnet.lan>
Date:	Fri, 12 Feb 2016 22:07:28 +0100
From:	Clemens Gruber <clemens.gruber@...ruber.com>
To:	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org,
	Sjoerd Simons <sjoerd.simons@...labora.co.uk>,
	"David S . Miller" <davem@...emloft.net>,
	Andrew Lunn <andrew@...n.ch>,
	Nimrod Andy <B38611@...escale.com>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	Lucas Stach <l.stach@...gutronix.de>,
	Russell King <rmk+kernel@....linux.org.uk>
Subject: Re: [PATCH] Revert "net: phy: turn carrier off on phy attach"

Hi Florian,

On Fri, Feb 12, 2016 at 10:56:04AM -0800, Florian Fainelli wrote:
> On 12/02/16 10:01, Clemens Gruber wrote:
> > Commit 113c74d83eef ("net: phy: turn carrier off on phy attach") breaks
> > the eth0 link coming up on all my i.MX6Q boards with a Marvell 88E1510.
> > If I then do a ifconfig eth0 down/up cycle I first get a MDIO read
> > timeout but then the link becomes ready and everything is back to
> > normal.
> > Without this step however, the link stays down forever, an unusually
> > high amount of phy interrupts occur (about 10000/second) and kworker/0:2
> > is constantly using over 60% of the CPU.
> > 
> > Reverting it fixes the problems with the link not coming up at boot as
> > well as the high amount of phy interrupts and kworker load in that
> > state.
> 
> You are seeing this with the FEC driver right? We probably want to
> carefully audit the driver and understand what could be going wrong, the
> initial change is correct, so there must be something else going on here.
> 

Yes, this occurs with the fec driver.

In the fec_probe function at line 3471 of
net/ethernet/freescale/fec_main.c, netif_carrier_off is called and a
comment states "Carrier starts down, phylib will bring it up".
Could this be the source of the problem, both fec and phy expecting the
other one to turn on the carrier?

If you have an idea about what could be going wrong in the fec driver,
please let me know.

Thanks,
Clemens