Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932429AbbBQCcK (ORCPT ); Mon, 16 Feb 2015 21:32:10 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:33738 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969AbbBQBu5 (ORCPT ); Mon, 16 Feb 2015 20:50:57 -0500 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Grant Likely" , "Ming Lei" , "Linus Walleij" Date: Tue, 17 Feb 2015 01:46:53 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 115/152] Fix circular locking dependency (3.3-rc2) In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.249 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7334 Lines: 156 3.2.67-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Ming Lei commit 864533ceb6db336dead389577c102a8b792a121a upstream. Hi, On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi wrote: > Hi guys, > > I have just triggered the folllowing: > > [   84.860321] ====================================================== > [   84.860321] [ INFO: possible circular locking dependency detected ] > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted > [   84.860321] ------------------------------------------------------- > [   84.860321] bash/949 is trying to acquire lock: > [   84.860321]  (sysfs_lock){+.+.+.}, at: [] gpio_value_store+0x24/0xcc > [   84.860321] > [   84.860321] but task is already holding lock: > [   84.860321]  (s_active#22){++++.+}, at: [] sysfs_write_file+0xdc/0x184 > [   84.911468] > [   84.911468] which lock already depends on the new lock. > [   84.911468] > [   84.920043] > [   84.920043] the existing dependency chain (in reverse order) is: > [   84.920043] > [   84.927886] -> #1 (s_active#22){++++.+}: > [   84.927886]        [] check_prevs_add+0xdc/0x150 > [   84.927886]        [] validate_chain.clone.24+0x564/0x694 > [   84.927886]        [] __lock_acquire+0x49c/0x980 > [   84.951660]        [] lock_acquire+0x98/0x100 > [   84.951660]        [] sysfs_deactivate+0xb0/0x100 > [   84.962982]        [] sysfs_addrm_finish+0x2c/0x6c > [   84.962982]        [] sysfs_remove_dir+0x84/0x98 > [   84.962982]        [] kobject_del+0x10/0x78 > [   84.974670]        [] device_del+0x140/0x170 > [   84.974670]        [] device_unregister+0xc/0x18 > [   84.985382]        [] gpio_unexport+0xbc/0xdc > [   84.985382]        [] gpio_free+0x14/0xfc > [   85.001708]        [] unexport_store+0x78/0x8c > [   85.001708]        [] class_attr_store+0x18/0x24 > [   85.007293]        [] sysfs_write_file+0x100/0x184 > [   85.018981]        [] vfs_write+0xb4/0x148 > [   85.018981]        [] sys_write+0x40/0x70 > [   85.018981]        [] ret_fast_syscall+0x0/0x3c > [   85.035003] > [   85.035003] -> #0 (sysfs_lock){+.+.+.}: > [   85.035003]        [] check_prev_add+0x680/0x698 > [   85.035003]        [] check_prevs_add+0xdc/0x150 > [   85.052093]        [] validate_chain.clone.24+0x564/0x694 > [   85.052093]        [] __lock_acquire+0x49c/0x980 > [   85.052093]        [] lock_acquire+0x98/0x100 > [   85.069885]        [] mutex_lock_nested+0x3c/0x2f4 > [   85.069885]        [] gpio_value_store+0x24/0xcc > [   85.069885]        [] dev_attr_store+0x18/0x24 > [   85.087158]        [] sysfs_write_file+0x100/0x184 > [   85.087158]        [] vfs_write+0xb4/0x148 > [   85.098297]        [] sys_write+0x40/0x70 > [   85.098297]        [] ret_fast_syscall+0x0/0x3c > [   85.109069] > [   85.109069] other info that might help us debug this: > [   85.109069] > [   85.117462]  Possible unsafe locking scenario: > [   85.117462] > [   85.117462]        CPU0                    CPU1 > [   85.128417]        ----                    ---- > [   85.128417]   lock(s_active#22); > [   85.128417]                                lock(sysfs_lock); > [   85.128417]                                lock(s_active#22); > [   85.142486]   lock(sysfs_lock); > [   85.151794] > [   85.151794]  *** DEADLOCK *** > [   85.151794] > [   85.151794] 2 locks held by bash/949: > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x28/0x184 > [   85.170349]  #1:  (s_active#22){++++.+}, at: [] sysfs_write_file+0xdc/0x184 > [   85.170349] > [   85.178588] stack backtrace: > [   85.178588] [] (unwind_backtrace+0x0/0xf0) from [] (print_circular_bug+0x100/0x114) > [   85.193023] [] (print_circular_bug+0x100/0x114) from [] (check_prev_add+0x680/0x698) > [   85.193023] [] (check_prev_add+0x680/0x698) from [] (check_prevs_add+0xdc/0x150) > [   85.212524] [] (check_prevs_add+0xdc/0x150) from [] (validate_chain.clone.24+0x564/0x694) > [   85.212524] [] (validate_chain.clone.24+0x564/0x694) from [] (__lock_acquire+0x49c/0x980) > [   85.233306] [] (__lock_acquire+0x49c/0x980) from [] (lock_acquire+0x98/0x100) > [   85.233306] [] (lock_acquire+0x98/0x100) from [] (mutex_lock_nested+0x3c/0x2f4) > [   85.242614] [] (mutex_lock_nested+0x3c/0x2f4) from [] (gpio_value_store+0x24/0xcc) > [   85.261840] [] (gpio_value_store+0x24/0xcc) from [] (dev_attr_store+0x18/0x24) > [   85.261840] [] (dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x100/0x184) > [   85.271240] [] (sysfs_write_file+0x100/0x184) from [] (vfs_write+0xb4/0x148) > [   85.290008] [] (vfs_write+0xb4/0x148) from [] (sys_write+0x40/0x70) > [   85.298400] [] (sys_write+0x40/0x70) from [] (ret_fast_syscall+0x0/0x3c) > -bash: echo: write error: Operation not permitted > > the way to trigger is: > > root@legolas:~# cd /sys/class/gpio/ > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# echo 2 > unexport > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# cd gpio2/ > root@legolas:/sys/class/gpio/gpio2# echo 1 > value Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may fix the problem. Acked-by: Linus Walleij Signed-off-by: Grant Likely Signed-off-by: Ben Hutchings --- drivers/gpio/gpiolib.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -877,6 +877,7 @@ void gpio_unexport(unsigned gpio) { struct gpio_desc *desc; int status = 0; + struct device *dev = NULL; if (!gpio_is_valid(gpio)) { status = -EINVAL; @@ -888,19 +889,20 @@ void gpio_unexport(unsigned gpio) desc = &gpio_desc[gpio]; if (test_bit(FLAG_EXPORT, &desc->flags)) { - struct device *dev = NULL; dev = class_find_device(&gpio_class, NULL, desc, match_export); if (dev) { gpio_setup_irq(desc, dev, 0); clear_bit(FLAG_EXPORT, &desc->flags); - put_device(dev); - device_unregister(dev); } else status = -ENODEV; } mutex_unlock(&sysfs_lock); + if (dev) { + device_unregister(dev); + put_device(dev); + } done: if (status) pr_debug("%s: gpio%d status %d\n", __func__, gpio, status); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/