From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755380AbZFUVft (ORCPT ); Sun, 21 Jun 2009 17:35:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754203AbZFUVfk (ORCPT ); Sun, 21 Jun 2009 17:35:40 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:53853 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753587AbZFUVfj (ORCPT ); Sun, 21 Jun 2009 17:35:39 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=YzTYISB2+l3Ms8Cyj3Z8za9ZVEVwNPiA8YNX7vlTNm6kvwJQvGtFyxt8glS8mUmNnt LuzPGn3XA+dSIX00VOHCX0uxB+yWLEO39T0d8HyHbgFlF81MCcY+Lf3IQ0TifbEdlcJk UnwNNfMZvmyZBR5qPpCrKbckkV0ULFeCfDW24= Date: Sun, 21 Jun 2009 23:35:25 +0200 From: Jarek Poplawski To: Andrea Righi Cc: Andrew Morton , linux-kernel@vger.kernel.org Subject: [2.6.30]fbdev: possible circular locking dependency in fb_mmap Message-ID: <20090621213525.GA2977@ami.dom.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I get this warning in vanilla 2.6.30. Reverting the patch below removes the warning. Regards, Jarek P. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.30f #39 ------------------------------------------------------- Xorg/2446 is trying to acquire lock: (&fb_info->lock){+.+.+.}, at: [] fb_mmap+0x97/0x170 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [] sys_mmap2+0x8e/0xc0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){++++++}: [] __lock_acquire+0xf26/0x17a0 [] lock_acquire+0x5e/0x80 [] might_fault+0x8b/0xb0 [] copy_to_user+0x36/0x120 [] filldir64+0xa4/0xf0 [] sysfs_readdir+0x129/0x220 [] vfs_readdir+0x86/0xa0 [] sys_getdents64+0x69/0xc0 [] syscall_call+0x7/0xb [] 0xffffffff -> #2 (sysfs_mutex){+.+.+.}: [] __lock_acquire+0xf26/0x17a0 [] lock_acquire+0x5e/0x80 [] mutex_lock_nested+0x57/0x300 [] sysfs_addrm_start+0x2c/0xb0 [] create_dir+0x40/0x90 [] sysfs_create_dir+0x2b/0x50 [] kobject_add_internal+0xc2/0x1b0 [] kobject_add_varg+0x31/0x50 [] kobject_add+0x2c/0x60 [] device_add+0xca/0x560 [] device_register+0x12/0x20 [] device_create_vargs+0xa2/0xb0 [] device_create+0x28/0x30 [] register_con_driver+0x14d/0x190 [] take_over_console+0x1b/0x430 [] fbcon_takeover+0x5c/0xb0 [] fbcon_event_notify+0x7de/0x810 [] notifier_call_chain+0x2d/0x70 [] __blocking_notifier_call_chain+0x44/0x60 [] blocking_notifier_call_chain+0x1a/0x20 [] fb_notifier_call_chain+0x11/0x20 [] register_framebuffer+0x173/0x230 [] vesafb_probe+0x542/0x783 [] platform_drv_probe+0xc/0x10 [] driver_probe_device+0x74/0x190 [] __device_attach+0x41/0x50 [] bus_for_each_drv+0x5b/0x80 [] device_attach+0x6b/0x70 [] bus_attach_device+0x47/0x70 [] device_add+0x330/0x560 [] platform_device_add+0x15d/0x1a0 [] vesafb_init+0x9a/0x1ec [] do_one_initcall+0x2a/0x160 [] kernel_init+0x8d/0xe1 [] kernel_thread_helper+0x7/0x1c [] 0xffffffff -> #1 ((fb_notifier_list).rwsem){.+.+.+}: [] __lock_acquire+0xf26/0x17a0 [] lock_acquire+0x5e/0x80 [] down_read+0x41/0x60 [] __blocking_notifier_call_chain+0x2a/0x60 [] blocking_notifier_call_chain+0x1a/0x20 [] fb_notifier_call_chain+0x11/0x20 [] register_framebuffer+0x173/0x230 [] vesafb_probe+0x542/0x783 [] platform_drv_probe+0xc/0x10 [] driver_probe_device+0x74/0x190 [] __device_attach+0x41/0x50 [] bus_for_each_drv+0x5b/0x80 [] device_attach+0x6b/0x70 [] bus_attach_device+0x47/0x70 [] device_add+0x330/0x560 [] platform_device_add+0x15d/0x1a0 [] vesafb_init+0x9a/0x1ec [] do_one_initcall+0x2a/0x160 [] kernel_init+0x8d/0xe1 [] kernel_thread_helper+0x7/0x1c [] 0xffffffff -> #0 (&fb_info->lock){+.+.+.}: [] __lock_acquire+0x1265/0x17a0 [] lock_acquire+0x5e/0x80 [] mutex_lock_nested+0x57/0x300 [] fb_mmap+0x97/0x170 [] mmap_region+0x2d6/0x450 [] do_mmap_pgoff+0x1ca/0x2f0 [] sys_mmap2+0xad/0xc0 [] sysenter_do_call+0x12/0x36 [] 0xffffffff other info that might help us debug this: 1 lock held by Xorg/2446: #0: (&mm->mmap_sem){++++++}, at: [] sys_mmap2+0x8e/0xc0 stack backtrace: Pid: 2446, comm: Xorg Not tainted 2.6.30f #39 Call Trace: [] ? printk+0x18/0x20 [] print_circular_bug_tail+0xc3/0xd0 [] ? print_circular_bug_entry+0x4b/0x50 [] __lock_acquire+0x1265/0x17a0 [] ? __generic_file_aio_write_nolock+0x23b/0x590 [] ? trace_hardirqs_on_caller+0x11c/0x160 [] lock_acquire+0x5e/0x80 [] ? fb_mmap+0x97/0x170 [] ? fb_mmap+0x97/0x170 [] mutex_lock_nested+0x57/0x300 [] ? fb_mmap+0x97/0x170 [] ? kmem_cache_alloc+0xb5/0x100 [] ? trace_hardirqs_on_caller+0x11c/0x160 [] fb_mmap+0x97/0x170 [] mmap_region+0x2d6/0x450 [] do_mmap_pgoff+0x1ca/0x2f0 [] sys_mmap2+0xad/0xc0 [] sysenter_do_call+0x12/0x36 ------------------> commit 513adb58685615b0b1d47a3f0d40f5352beff189 Author: Andrea Righi Date: Mon Apr 13 14:39:39 2009 -0700 fbdev: fix info->lock deadlock in fbcon_event_notify() fb_notifier_call_chain() is called with info->lock held, i.e. in do_fb_ioctl() => FBIOPUT_VSCREENINFO => fb_set_var() and the some notifier callbacks, like fbcon_event_notify(), try to re-acquire info->lock again. Remove the lock/unlock_fb_info() in all the framebuffer notifier callbacks' and be sure to always call fb_notifier_call_chain() with info->lock held.