mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: tglx@linutronix.de
Cc: Lucas Stach <l.stach@pengutronix.de>,
	Chris Healy <cphealy@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: lockdep annotation for desc->request_mutex
Date: Thu, 9 Nov 2017 19:00:59 +0100	[thread overview]
Message-ID: <20171109180059.GG13277@lunn.ch> (raw)

Hi Thomas

I'm been given reports of a new lockdep splat while testing
4.14-rc8. It appears to be a false positive, due to missing lockdep
annotation on desc->request_mutex. The driver is using two different
interrupt descriptors via different paths. But without annotation,
lockdep thinks it is the same mutex.

Do you have patches adding a lockdep class for desc->request_mutex?

Thanks
	Andrew

[    2.588384] ======================================================
[    2.593311] WARNING: possible circular locking dependency detected
[    2.598246] 4.14.0-rc7-02257-g19aeeb9f46cb #351 Not tainted
[    2.602566] ------------------------------------------------------
[    2.607493] kworker/0:0/3 is trying to acquire lock:
[    2.611199]  (&chip->reg_lock){+.+.}, at: [<804ebe24>] mv88e6xxx_g1_irq_bus_lock+0x24/0x28
[    2.618285] 
               but task is already holding lock:
[    2.621560]  (&desc->request_mutex){+.+.}, at: [<8016685c>] __setup_irq+0xb4/0x6c8
[    2.627930] 
               which lock already depends on the new lock.

[    2.632259] 
               the existing dependency chain (in reverse order) is:
[    2.637194] 
               -> #1 (&desc->request_mutex){+.+.}:
[    2.640688]        __mutex_lock+0x8c/0x6e0
[    2.643525]        mutex_lock_nested+0x2c/0x34
[    2.646713]        __setup_irq+0xb4/0x6c8
[    2.649461]        request_threaded_irq+0xec/0x160
[    2.653000]        mv88e6xxx_probe+0x3e0/0x44c
[    2.656195]        mdio_probe+0x28/0x34
[    2.658776]        driver_probe_device+0x248/0x2f8
[    2.662310]        __device_attach_driver+0xa8/0xdc
[    2.665938]        bus_for_each_drv+0x54/0xa4
[    2.669040]        __device_attach+0xc4/0x128
[    2.672139]        device_initial_probe+0x1c/0x20
[    2.675586]        bus_probe_device+0x98/0xa0
[    2.678691]        device_add+0x3a4/0x598
[    2.681442]        mdio_device_register+0x34/0x58
[    2.684900]        of_mdiobus_register+0x154/0x298
[    2.688442]        mdio_mux_init+0x168/0x2e8
[    2.691458]        mdio_mux_gpio_probe+0x80/0xb4
[    2.694821]        platform_drv_probe+0x60/0xbc
[    2.698097]        driver_probe_device+0x248/0x2f8
[    2.701631]        __device_attach_driver+0xa8/0xdc
[    2.705258]        bus_for_each_drv+0x54/0xa4
[    2.708361]        __device_attach+0xc4/0x128
[    2.711460]        device_initial_probe+0x1c/0x20
[    2.714907]        bus_probe_device+0x98/0xa0
[    2.718003]        deferred_probe_work_func+0x6c/0x158
[    2.721894]        process_one_work+0x2b8/0x764
[    2.725174]        worker_thread+0x2c8/0x5d4
[    2.728189]        kthread+0x17c/0x184
[    2.730687]        ret_from_fork+0x14/0x2c
[    2.733520]
                -> #0 (&chip->reg_lock){+.+.}:
[    2.736579]        lock_acquire+0xe4/0x22c
[    2.739420]        __mutex_lock+0x8c/0x6e0
[    2.742257]        mutex_lock_nested+0x2c/0x34
[    2.745445]        mv88e6xxx_g1_irq_bus_lock+0x24/0x28
[    2.749331]        __setup_irq+0x5cc/0x6c8
[    2.752170]        request_threaded_irq+0xec/0x160
[    2.755721]        mv88e6xxx_g2_irq_setup+0x13c/0x1dc
[    2.759518]        mv88e6xxx_probe+0x284/0x44c
[    2.762708]        mdio_probe+0x28/0x34
[    2.765289]        driver_probe_device+0x248/0x2f8
[    2.768828]        __device_attach_driver+0xa8/0xdc
[    2.772454]        bus_for_each_drv+0x54/0xa4
[    2.775558]        __device_attach+0xc4/0x128
[    2.778656]        device_initial_probe+0x1c/0x20
[    2.782103]        bus_probe_device+0x98/0xa0
[    2.785204]        device_add+0x3a4/0x598
[    2.787960]        mdio_device_register+0x34/0x58
[    2.791411]        of_mdiobus_register+0x154/0x298
[    2.794951]        mdio_mux_init+0x168/0x2e8
[    2.797968]        mdio_mux_gpio_probe+0x80/0xb4
[    2.801327]        platform_drv_probe+0x60/0xbc
[    2.804606]        driver_probe_device+0x248/0x2f8
[    2.808140]        __device_attach_driver+0xa8/0xdc
[    2.811767]        bus_for_each_drv+0x54/0xa4
[    2.814871]        __device_attach+0xc4/0x128
[    2.817969]        device_initial_probe+0x1c/0x20
[    2.821416]        bus_probe_device+0x98/0xa0
[    2.824512]        deferred_probe_work_func+0x6c/0x158
[    2.828399]        process_one_work+0x2b8/0x764
[    2.831674]        worker_thread+0x2c8/0x5d4
[    2.834686]        kthread+0x17c/0x184
[    2.837173]        ret_from_fork+0x14/0x2c
[    2.840003] 
               other info that might help us debug this:

[    2.844157]  Possible unsafe locking scenario:

[    2.847519]        CPU0                    CPU1
[    2.850783]        ----                    ----
[    2.854045]   lock(&desc->request_mutex);
[    2.856802]                                lock(&chip->reg_lock);
[    2.861659]                                lock(&desc->request_mutex);
[    2.866947]   lock(&chip->reg_lock);
[    2.869269] 
                *** DEADLOCK ***
[    2.871327] 5 locks held by kworker/0:0/3:
[    2.874161]  #0:  ("events"){+.+.}, at: [<80135a74>] process_one_work+0x1ec/0x764
[    2.880443]  #1:  (deferred_probe_work){+.+.}, at: [<80135a74>] process_one_work+0x1ec/0x764
[    2.887688]  #2:  (&dev->mutex){....}, at: [<80481974>] __device_attach+0x30/0x128
[    2.894060]  #3:  (&dev->mutex){....}, at: [<80481974>] __device_attach+0x30/0x128
[    2.900430]  #4:  (&desc->request_mutex){+.+.}, at: [<8016685c>] __setup_irq+0xb4/0x6c8
[    2.907236] 

             reply	other threads:[~2017-11-09 18:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09 18:00 Andrew Lunn [this message]
2017-11-13 14:11 ` Thomas Gleixner

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=20171109180059.GG13277@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®