Re: [Linux-fbdev-devel] [2.6.29-rc2] fb_mmap: circular locking dependency on hibernation

From: Andrea Righi
Date: Thu Jan 29 2009 - 05:03:36 EST


On Thu, Jan 29, 2009 at 10:10 AM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> 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: [<c0223017>] fb_mmap+0x97/0x170
>> [11715.652623]
>> [11715.652625] but task is already holding lock:
>> [11715.652632] (&mm->mmap_sem){----}, at: [<c010639e>] 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] [<c0144ecf>] __lock_acquire+0x129f/0x1930
>> [11715.652730] [<c01455bc>] lock_acquire+0x5c/0x80
>> [11715.652742] [<c0181e57>] might_fault+0x77/0xa0
>> [11715.652764] [<c0209325>] copy_from_user+0x35/0x130
>> [11715.652782] [<c0223ef5>] fb_ioctl+0x1d5/0x3f0
>> [11715.652797] [<c01a51d0>] vfs_ioctl+0x20/0x80
>> [11715.652832] [<c01a53e2>] do_vfs_ioctl+0x72/0x570
>> [11715.652845] [<c01a5919>] sys_ioctl+0x39/0x70
>> [11715.652857] [<c0103371>] sysenter_do_call+0x12/0x31
>> [11715.652870] [<ffffffff>] 0xffffffff
>> [11715.652973]
>> [11715.652975] -> #0 (&fb_info->lock){--..}:
>> [11715.652988] [<c014503c>] __lock_acquire+0x140c/0x1930
>> [11715.653000] [<c01455bc>] lock_acquire+0x5c/0x80
>> [11715.653011] [<c030761a>] mutex_lock_nested+0xba/0x2f0
>> [11715.653032] [<c0223017>] fb_mmap+0x97/0x170
>> [11715.653044] [<c0188996>] mmap_region+0x1d6/0x530
>> [11715.653067] [<c0188ec3>] do_mmap_pgoff+0x1d3/0x2f0
>> [11715.653079] [<c01063bd>] sys_mmap2+0xad/0xc0
>> [11715.653091] [<c0103371>] sysenter_do_call+0x12/0x31
>> [11715.653102] [<ffffffff>] 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: [<c010639e>]
>> 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] [<c0306248>] ? printk+0x18/0x20
>> [11715.653202] [<c01437df>] print_circular_bug_tail+0xcf/0xe0
>> [11715.653213] [<c014503c>] __lock_acquire+0x140c/0x1930
>> [11715.653224] [<c014328b>] ? trace_hardirqs_on+0xb/0x10
>> [11715.653242] [<c0309125>] ? _spin_unlock_irqrestore+0x35/0x60
>> [11715.653254] [<c0140dc5>] ? lock_release_holdtime+0x35/0x210
>> [11715.653265] [<c01455bc>] lock_acquire+0x5c/0x80
>> [11715.653277] [<c0223017>] ? fb_mmap+0x97/0x170
>> [11715.653287] [<c030761a>] mutex_lock_nested+0xba/0x2f0
>> [11715.653298] [<c0223017>] ? fb_mmap+0x97/0x170
>> [11715.653309] [<c0223017>] ? fb_mmap+0x97/0x170
>> [11715.653335] [<c019514d>] ? kmem_cache_alloc+0xad/0x100
>> [11715.653347] [<c0223017>] fb_mmap+0x97/0x170
>> [11715.653358] [<c0188996>] mmap_region+0x1d6/0x530
>> [11715.653371] [<c0186a9d>] ? arch_get_unmapped_area_topdown+0x10d/0x170
>> [11715.653383] [<c0188ec3>] do_mmap_pgoff+0x1d3/0x2f0
>> [11715.653395] [<c01063bd>] sys_mmap2+0xad/0xc0
>> [11715.653406] [<c0103371>] sysenter_do_call+0x12/0x31
>
> Is this fixed by http://patchwork.kernel.org/patch/3259/?

Correct.

As I said in the note there're still some potential deadlocks into
some driver's specific fb_ioctl(), but at least for the common
fb_ioctl() implementation, and for this problem in particular, the
patch avoids the circular locking.

-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/