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

[Geert Uytterhoeven]

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/?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
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/