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] [day] [month] [year] [list]
Message-ID: <Y4u17vz20EemzxEB@lunn.ch>
Date:   Sat, 3 Dec 2022 21:47:42 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Frank <Frank.Sae@...or-comm.com>, Peter Geis <pgwipeout@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, yinghong.zhang@...or-comm.com,
        fei.zhang@...or-comm.com, hua.sun@...or-comm.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net: phy: Add driver for Motorcomm yt8531
 gigabit ethernet phy

On Fri, Dec 02, 2022 at 01:34:16PM +0000, Russell King (Oracle) wrote:
> On Fri, Dec 02, 2022 at 02:27:43PM +0100, Andrew Lunn wrote:
> > > +static bool mdio_is_locked(struct phy_device *phydev)
> > > +{
> > > +	return mutex_is_locked(&phydev->mdio.bus->mdio_lock);
> > > +}
> > > +
> > > +#define ASSERT_MDIO(phydev) \
> > > +	WARN_ONCE(!mdio_is_locked(phydev), \
> > > +		  "MDIO: assertion failed at %s (%d)\n", __FILE__,  __LINE__)
> > > +
> > 
> > Hi Frank
> > 
> > You are not the only one who gets locking wrong. This could be used in
> > other drivers. Please add it to include/linux/phy.h,
> 
> That placement doesn't make much sense.
> 
> As I already said, we have lockdep checks in drivers/net/phy/mdio_bus.c,
> and if we want to increase their effectiveness, then that's the place
> that it should be done.

I was following the ASSERT_RTNL model, but that is used in quite deep
and complex call stacks, and it is useful to scatter the macro in lots
of places. PHY drivers are however very shallow, so yes, putting them
in mdio_bus.c makes a lot of sense.

> I don't see any point in using __FILE__ and __LINE__ in the above
> macro either. Firstly, WARN_ONCE() already includes the file and line,
> and secondly, the backtrace is more useful than the file and line where
> the assertion occurs especially if it's placed in mdio_bus.c

And PHY driver functions are simpler, there is a lot less inlining
going on, so the function name is probably all you need to know to
find where you messed up the locking. So i agree, they can be removed.

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ