| 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
| ||
|
Message-ID: <20171109180059.GG13277@lunn.ch>
Date: Thu, 9 Nov 2017 19:00:59 +0100
From: Andrew Lunn <andrew@...n.ch>
To: tglx@...utronix.de
Cc: Lucas Stach <l.stach@...gutronix.de>,
Chris Healy <cphealy@...il.com>, linux-kernel@...r.kernel.org
Subject: lockdep annotation for desc->request_mutex
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]
Powered by blists - more mailing lists