[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4eT25bT7T8W6UXW@shell.armlinux.org.uk>
Date: Wed, 30 Nov 2022 17:33:15 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
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] net: phy: Add driver for Motorcomm yt8531
gigabit ethernet phy
Hi Andrew,
On Wed, Nov 30, 2022 at 06:10:42PM +0100, Andrew Lunn wrote:
> This is not the first time Russell has pointed out your locking is
> wrong.
>
> How about adding a check in functions which should be called with the
> lock taken really do have the lock taken?
They already do:
lockdep_assert_held_once(&bus->mdio_lock);
but I guess people just aren't testing their code with lockdep enabled.
The only other thing I can think of trying is to use mutex_trylock():
if (WARN_ON_ONCE(mutex_trylock(&bus->mdio_lock)))
mutex_unlock(&bus->mdio_lock);
scattered throughout.
However, if the author does have lockdep enabled but ignores the
warnings, that isn't going to help.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists