From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753873AbdKISBE (ORCPT ); Thu, 9 Nov 2017 13:01:04 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:50576 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753086AbdKISBC (ORCPT ); Thu, 9 Nov 2017 13:01:02 -0500 Date: Thu, 9 Nov 2017 19:00:59 +0100 From: Andrew Lunn To: tglx@linutronix.de Cc: Lucas Stach , Chris Healy , linux-kernel@vger.kernel.org Subject: lockdep annotation for desc->request_mutex Message-ID: <20171109180059.GG13277@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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]