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: <8435724.NyiUUSuA9g@fw-rgant>
Date: Tue, 02 Jul 2024 11:04:37 +0200
From: Romain Gantois <romain.gantois@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
 Russell King <linux@...linux.org.uk>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH net-next 6/6] net: phy: dp83869: Fix link up reporting in SGMII
 bridge mode

On lundi 1 juillet 2024 19:09:40 UTC+2 Andrew Lunn wrote:
> > +			if (dp83869->mod_phy) {
> > +				ret = phy_read_status(dp83869->mod_phy);
> > +				if (ret)
> > +					return ret;
> 
> Locking? When phylib does this in phy_check_link_status(), we have:
> 
> 	lockdep_assert_held(&phydev->lock);
> 
> I don't see anything which takes the downstreams PHY lock.
> 
> Is this also introducing race conditions? What happens if the link
> just went down? phy_check_link_status() takes actions. Will they still
> happen when phylib next talks to the downstream PHY? It is probably
> safer to call phy_check_link_status() than phy_read_status().

Given that the phylib state machine will call phy_check_link_status() itself,
I think that this call to phy_read_status() could be dropped entirely and that
dp83869_read_status() could just directly read mod_phy->{link,speed,duplex}.

This raises the question of a potential race condition when reading
mod_phy->{link, speed, duplex}. I haven't seen any kind of locking used in
other parts of the net subsystem when reading these parameters.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ