Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754701AbZAaPxj (ORCPT ); Sat, 31 Jan 2009 10:53:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752484AbZAaPxb (ORCPT ); Sat, 31 Jan 2009 10:53:31 -0500 Received: from mail-ew0-f21.google.com ([209.85.219.21]:43995 "EHLO mail-ew0-f21.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437AbZAaPx3 (ORCPT ); Sat, 31 Jan 2009 10:53:29 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=DT0EypUk0vaG/rm7VEWg7FDW2z5MWJ+yxSE5xk1c16x1K4SofXKGLl/59G9B5T7TGv xe+1gL1giaTuKW6EJdn9BqoJi7xPBOTiailDeT1J5sLe9nSYII1JtxDLy0nUWTDMPGEq fAv7epk3EUvwNRQhQypYs3vCaa4APEb7Cq0uI= Message-ID: <498473F3.3050208@gmail.com> Date: Sat, 31 Jan 2009 16:53:23 +0100 From: Andrea Righi Reply-To: righi.andrea@gmail.com User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Andrey Borzenkov CC: Geert Uytterhoeven , Linux Frame Buffer Device Development , "Antonino A. Daplas" , linux-pm@lists.linux-foundation.org, Linux Kernel Development Subject: Re: [Linux-fbdev-devel] [2.6.29-rc2] fb_mmap: circular locking dependency on hibernation References: <200901272137.57757.arvidjaar@mail.ru> <200901300716.06137.arvidjaar@mail.ru> <4982D522.20009@gmail.com> In-Reply-To: <4982D522.20009@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 11849 Lines: 233 On 2009-01-30 11:23, Andrea Righi wrote: > On 2009-01-30 05:15, Andrey Borzenkov wrote: >> On 29 of January 2009 12:10:11 Geert Uytterhoeven wrote: >>> On Tue, 27 Jan 2009, Andrey Borzenkov wrote: >>>> I do not know if this is new; I usually do not hibernate at all and >>>> was testing another driver actually. I do not remember such issues >>>> in 2.6.28 though. Dmesg follows; config attached. >>>> >>>> [11715.652498] >>>> ======================================================= >>>> [11715.652520] [ INFO: possible circular locking dependency >>>> detected ] [11715.652534] 2.6.29-rc2-1avb #11 >>>> [11715.652541] >>>> ------------------------------------------------------- >>>> [11715.652550] s2disk/25519 is trying to acquire lock: >>>> [11715.652562] (&fb_info->lock){--..}, at: [] >>>> fb_mmap+0x97/0x170 [11715.652623] >>>> [11715.652625] but task is already holding lock: >>>> [11715.652632] (&mm->mmap_sem){----}, at: [] >>>> sys_mmap2+0x8e/0xc0 [11715.652669] >>>> [11715.652671] which lock already depends on the new lock. >>>> [11715.652675] >>>> [11715.652681] >>>> [11715.652683] the existing dependency chain (in reverse order) is: >>>> [11715.652691] >>>> [11715.652693] -> #1 (&mm->mmap_sem){----}: >>>> [11715.652707] [] __lock_acquire+0x129f/0x1930 >>>> [11715.652730] [] lock_acquire+0x5c/0x80 >>>> [11715.652742] [] might_fault+0x77/0xa0 >>>> [11715.652764] [] copy_from_user+0x35/0x130 >>>> [11715.652782] [] fb_ioctl+0x1d5/0x3f0 >>>> [11715.652797] [] vfs_ioctl+0x20/0x80 >>>> [11715.652832] [] do_vfs_ioctl+0x72/0x570 >>>> [11715.652845] [] sys_ioctl+0x39/0x70 >>>> [11715.652857] [] sysenter_do_call+0x12/0x31 >>>> [11715.652870] [] 0xffffffff >>>> [11715.652973] >>>> [11715.652975] -> #0 (&fb_info->lock){--..}: >>>> [11715.652988] [] __lock_acquire+0x140c/0x1930 >>>> [11715.653000] [] lock_acquire+0x5c/0x80 >>>> [11715.653011] [] mutex_lock_nested+0xba/0x2f0 >>>> [11715.653032] [] fb_mmap+0x97/0x170 >>>> [11715.653044] [] mmap_region+0x1d6/0x530 >>>> [11715.653067] [] do_mmap_pgoff+0x1d3/0x2f0 >>>> [11715.653079] [] sys_mmap2+0xad/0xc0 >>>> [11715.653091] [] sysenter_do_call+0x12/0x31 >>>> [11715.653102] [] 0xffffffff >>>> [11715.653116] >>>> [11715.653119] other info that might help us debug this: >>>> [11715.653122] >>>> [11715.653130] 1 lock held by s2disk/25519: >>>> [11715.653137] #0: (&mm->mmap_sem){----}, at: [] >>>> sys_mmap2+0x8e/0xc0 >>>> [11715.653156] >>>> [11715.653158] stack backtrace: >>>> [11715.653170] Pid: 25519, comm: s2disk Not tainted 2.6.29-rc2-1avb >>>> #11 [11715.653179] Call Trace: >>>> [11715.653190] [] ? printk+0x18/0x20 >>>> [11715.653202] [] print_circular_bug_tail+0xcf/0xe0 >>>> [11715.653213] [] __lock_acquire+0x140c/0x1930 >>>> [11715.653224] [] ? trace_hardirqs_on+0xb/0x10 >>>> [11715.653242] [] ? _spin_unlock_irqrestore+0x35/0x60 >>>> [11715.653254] [] ? lock_release_holdtime+0x35/0x210 >>>> [11715.653265] [] lock_acquire+0x5c/0x80 >>>> [11715.653277] [] ? fb_mmap+0x97/0x170 >>>> [11715.653287] [] mutex_lock_nested+0xba/0x2f0 >>>> [11715.653298] [] ? fb_mmap+0x97/0x170 >>>> [11715.653309] [] ? fb_mmap+0x97/0x170 >>>> [11715.653335] [] ? kmem_cache_alloc+0xad/0x100 >>>> [11715.653347] [] fb_mmap+0x97/0x170 >>>> [11715.653358] [] mmap_region+0x1d6/0x530 >>>> [11715.653371] [] ? >>>> arch_get_unmapped_area_topdown+0x10d/0x170 [11715.653383] >>>> [] do_mmap_pgoff+0x1d3/0x2f0 >>>> [11715.653395] [] sys_mmap2+0xad/0xc0 >>>> [11715.653406] [] sysenter_do_call+0x12/0x31 >>> Is this fixed by http://patchwork.kernel.org/patch/3259/? >>> >> No. It just makes stack a bit more deep :) > > yep! :) > > Probably we should simply use an atomic notifier there, instead of blocking. > I'll do some tests and post a new fix. No, the solution is no so trivial. Some notifier callbacks can sleep, so the usage of a blocking notifier is mandatory. It seems we need a more complicated solution to totally fix it. At least the previous fix avoids the circular locking of fb_info->lock and mm->mmap_sem due to copy_from/to_user() called with fb_info->lock held... -Andrea > > Thanks, > -Andrea > >> [ 408.267429] ======================================================= >> [ 408.267448] [ INFO: possible circular locking dependency detected ] >> [ 408.267462] 2.6.29-rc3-1avb #14 >> [ 408.267469] ------------------------------------------------------- >> [ 408.267478] s2disk/5695 is trying to acquire lock: >> [ 408.267487] (&fb_info->lock){--..}, at: [] >> fb_mmap+0x97/0x170 >> [ 408.267544] >> [ 408.267546] but task is already holding lock: >> [ 408.267553] (&mm->mmap_sem){----}, at: [] >> sys_mmap2+0x8e/0xc0 >> [ 408.267591] >> [ 408.267593] which lock already depends on the new lock. >> [ 408.267596] >> [ 408.267603] >> [ 408.267604] the existing dependency chain (in reverse order) is: >> [ 408.267612] >> [ 408.267614] -> #3 (&mm->mmap_sem){----}: >> [ 408.267628] [] __lock_acquire+0x129f/0x1930 >> [ 408.267650] [] lock_acquire+0x5c/0x80 >> [ 408.267661] [] might_fault+0x77/0xa0 >> [ 408.267683] [] copy_to_user+0x36/0x120 >> [ 408.267699] [] filldir+0x97/0xe0 >> [ 408.267735] [] sysfs_readdir+0x129/0x220 >> [ 408.267751] [] vfs_readdir+0x86/0xa0 >> [ 408.267763] [] sys_getdents+0x68/0xc0 >> [ 408.267775] [] syscall_call+0x7/0xb >> [ 408.267787] [] 0xffffffff >> [ 408.267862] >> [ 408.267864] -> #2 (sysfs_mutex){--..}: >> [ 408.267877] [] __lock_acquire+0x129f/0x1930 >> [ 408.267889] [] lock_acquire+0x5c/0x80 >> [ 408.267899] [] mutex_lock_nested+0xba/0x2f0 >> [ 408.267921] [] sysfs_addrm_start+0x2c/0xc0 >> [ 408.267933] [] create_dir+0x40/0x90 >> [ 408.267944] [] sysfs_create_dir+0x2b/0x50 >> [ 408.267955] [] kobject_add_internal+0xbc/0x1b0 >> [ 408.267984] [] kobject_add_varg+0x31/0x50 >> [ 408.267996] [] kobject_add+0x2c/0x60 >> [ 408.268008] [] device_add+0xa8/0x550 >> [ 408.268041] [] device_register+0x12/0x20 >> [ 408.268053] [] device_create_vargs+0xab/0xc0 >> [ 408.268065] [] device_create+0x28/0x30 >> [ 408.268077] [] register_con_driver+0xed/0x130 >> [ 408.268090] [] take_over_console+0x1b/0x50 >> [ 408.268102] [] fbcon_takeover+0x5d/0xb0 >> [ 408.268125] [] fbcon_event_notify+0x820/0x900 >> [ 408.268137] [] notifier_call_chain+0x53/0xa0 >> [ 408.268161] [] >> __blocking_notifier_call_chain+0x44/0x60 >> [ 408.268184] [] >> blocking_notifier_call_chain+0x1a/0x20 >> [ 408.268197] [] fb_notifier_call_chain+0x11/0x20 >> [ 408.268209] [] register_framebuffer+0x168/0x220 >> [ 408.268223] [] vesafb_probe+0x542/0x783 >> [ 408.268250] [] platform_drv_probe+0xf/0x20 >> [ 408.268269] [] driver_probe_device+0x87/0x1b0 >> [ 408.268281] [] __device_attach+0x8/0x10 >> [ 408.268291] [] bus_for_each_drv+0x5b/0x80 >> [ 408.268308] [] device_attach+0x76/0x80 >> [ 408.268319] [] bus_attach_device+0x47/0x70 >> [ 408.268331] [] device_add+0x323/0x550 >> [ 408.268342] [] platform_device_add+0x175/0x1c0 >> [ 408.268358] [] vesafb_init+0x9a/0x1ec >> [ 408.268370] [] do_one_initcall+0x2a/0x160 >> [ 408.268382] [] kernel_init+0x83/0xd5 >> [ 408.268411] [] kernel_thread_helper+0x7/0x10 >> [ 408.268423] [] 0xffffffff >> [ 408.268436] >> [ 408.268438] -> #1 ((fb_notifier_list).rwsem){----}: >> [ 408.268451] [] __lock_acquire+0x129f/0x1930 >> [ 408.268463] [] lock_acquire+0x5c/0x80 >> [ 408.268474] [] down_read+0x49/0x90 >> [ 408.268484] [] >> __blocking_notifier_call_chain+0x2a/0x60 >> [ 408.268497] [] >> blocking_notifier_call_chain+0x1a/0x20 >> [ 408.268509] [] fb_notifier_call_chain+0x11/0x20 >> [ 408.268521] [] do_fb_ioctl+0x2ae/0x5d0 >> [ 408.268533] [] fb_ioctl+0x1d/0x20 >> [ 408.268545] [] vfs_ioctl+0x20/0x80 >> [ 408.268558] [] do_vfs_ioctl+0x72/0x570 >> [ 408.268570] [] sys_ioctl+0x39/0x70 >> [ 408.268581] [] sysenter_do_call+0x12/0x31 >> [ 408.268592] [] 0xffffffff >> [ 408.268623] >> [ 408.268625] -> #0 (&fb_info->lock){--..}: >> [ 408.268638] [] __lock_acquire+0x140c/0x1930 >> [ 408.268649] [] lock_acquire+0x5c/0x80 >> [ 408.268661] [] mutex_lock_nested+0xba/0x2f0 >> [ 408.268672] [] fb_mmap+0x97/0x170 >> [ 408.268684] [] mmap_region+0x1d6/0x530 >> [ 408.268706] [] do_mmap_pgoff+0x1d3/0x2f0 >> [ 408.268718] [] sys_mmap2+0xad/0xc0 >> [ 408.268729] [] sysenter_do_call+0x12/0x31 >> [ 408.268740] [] 0xffffffff >> [ 408.268752] >> [ 408.268754] other info that might help us debug this: >> [ 408.268758] >> [ 408.268767] 1 lock held by s2disk/5695: >> [ 408.268773] #0: (&mm->mmap_sem){----}, at: [] >> sys_mmap2+0x8e/0xc0 >> [ 408.268792] >> [ 408.268794] stack backtrace: >> [ 408.268805] Pid: 5695, comm: s2disk Not tainted 2.6.29-rc3-1avb #14 >> [ 408.268814] Call Trace: >> [ 408.268825] [] ? printk+0x18/0x20 >> [ 408.268836] [] print_circular_bug_tail+0xcf/0xe0 >> [ 408.268847] [] __lock_acquire+0x140c/0x1930 >> [ 408.268862] [] ? futex_wait+0x170/0x450 >> [ 408.268881] [] ? try_to_wake_up+0x10c/0x120 >> [ 408.268894] [] ? _spin_unlock_irqrestore+0x35/0x60 >> [ 408.268906] [] ? lock_release_holdtime+0x35/0x210 >> [ 408.268917] [] lock_acquire+0x5c/0x80 >> [ 408.268928] [] ? fb_mmap+0x97/0x170 >> [ 408.268939] [] mutex_lock_nested+0xba/0x2f0 >> [ 408.268950] [] ? fb_mmap+0x97/0x170 >> [ 408.268961] [] ? fb_mmap+0x97/0x170 >> [ 408.268987] [] ? kmem_cache_alloc+0xad/0x100 >> [ 408.268999] [] fb_mmap+0x97/0x170 >> [ 408.269010] [] mmap_region+0x1d6/0x530 >> [ 408.269023] [] ? >> arch_get_unmapped_area_topdown+0x10d/0x170 >> [ 408.269035] [] do_mmap_pgoff+0x1d3/0x2f0 >> [ 408.269047] [] sys_mmap2+0xad/0xc0 >> [ 408.269058] [] sysenter_do_call+0x12/0x31 -- Andrea Righi Jabber ID: righiandr@jabber.linux.it gpg --keyserver pgp.mit.edu --recv-keys 77CEF397 -- 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/