All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	Jakub Kicinski <kuba@kernel.org>,
	David Miller <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] net: phy: replace mutex_is_locked with lockdep_assert_held in phylib
Date: Thu, 7 Jan 2021 00:18:41 +0100	[thread overview]
Message-ID: <17717d40-ff36-dd59-bfaf-0abb513bab06@gmail.com> (raw)
In-Reply-To: <X/Y8D2TgQDBumfvO@lunn.ch>

On 06.01.2021 23:39, Andrew Lunn wrote:
> On Wed, Jan 06, 2021 at 02:03:40PM +0100, Heiner Kallweit wrote:
>> Switch to lockdep_assert_held(_once), similar to what is being done
>> in other subsystems. One advantage is that there's zero runtime
>> overhead if lockdep support isn't enabled.
> 
> Hi Heiner
> 
Hi Andrew,

> I'm not sure we are bothered about performance here. MDIO operations
> are slow, a mutex check is fast relative to that.
> 
Right, the performance gain is neglectible here.

What I see is that more and more similar checks (e.g. in_softirq,
in_irq) are migrated to the lockdep framework. And as stated in the
commit message I've seen a number of equivalent patches in other
subsystems.

> I wonder how many do development work with lockdep enabled? I think i
> prefer catching hard to find locking bugs earlier, verses a tiny
> performance overhead.
> 
Well, I always develop with lockdep enabled and like the fact that it
provides a multitude of checks with minimal overhead. Would be
interesting to know the ratio of kernel developers counting on lockdep.

>        Andrew
> 
Heiner

  reply	other threads:[~2021-01-06 23:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 13:03 [PATCH net-next] net: phy: replace mutex_is_locked with lockdep_assert_held in phylib Heiner Kallweit
2021-01-06 22:39 ` Andrew Lunn
2021-01-06 23:18   ` Heiner Kallweit [this message]
2021-01-07 21:15 ` Andrew Lunn
2021-01-07 22:55   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17717d40-ff36-dd59-bfaf-0abb513bab06@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.