mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Linux Frame Buffer Device Development 
	<linux-fbdev-devel@lists.sourceforge.net>,
	"Antonino A. Daplas" <adaplas@gmail.com>,
	linux-pm@lists.linux-foundation.org,
	Linux Kernel Development <linux-kernel@vger.kernel.org>,
	Andrea Righi <righi.andrea@gmail.com>
Subject: Re: [Linux-fbdev-devel] [2.6.29-rc2] fb_mmap: circular locking dependency on hibernation
Date: Thu, 29 Jan 2009 10:10:11 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0901291009220.13600@anakin> (raw)
In-Reply-To: <200901272137.57757.arvidjaar@mail.ru>

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@linux-m68k.org

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

  reply	other threads:[~2009-01-29  9:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-27 18:37 Andrey Borzenkov
2009-01-29  9:10 ` Geert Uytterhoeven [this message]
2009-01-29 10:03   ` [Linux-fbdev-devel] " Andrea Righi
2009-01-30  4:15   ` Andrey Borzenkov
2009-01-30 10:23     ` Andrea Righi
2009-01-31 15:53       ` Andrea Righi
2009-01-31 16:05         ` Andrey Borzenkov
2009-01-31 17:09     ` Andrea Righi
2009-01-31 17:44       ` Geert Uytterhoeven
2009-01-31 18:11         ` Andrea Righi
2009-02-01  7:15       ` Andrey Borzenkov
2009-02-01 22:50         ` Andrea Righi
2009-02-02 17:36           ` Andrey Borzenkov
2009-02-03 10:09             ` Andrea Righi
2009-02-04  8:19               ` Andrey Borzenkov
2009-02-04 21:46               ` [PATCH -mmotm] fbmem: fix fb_info->lock and mm->mmap_sem circular locking dependency Andrea Righi
2009-02-04 23:58                 ` Rafael J. Wysocki
2009-02-05  1:49                   ` Rafael J. Wysocki
2009-03-22 14:48                 ` Andrey Borzenkov
2009-03-22 17:57                   ` Rafael J. Wysocki
2009-03-22 21:52                     ` Andrew Morton
2009-04-06 18:47                       ` commit 66c1ca breaks fbdev mode switching Krzysztof Helt
2009-04-06 21:45                         ` Andrea Righi
2009-04-07  9:17                           ` Geert Uytterhoeven
2009-04-07  9:54                             ` Andrea Righi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0901291009220.13600@anakin \
    --to=geert@linux-m68k.org \
    --cc=adaplas@gmail.com \
    --cc=arvidjaar@mail.ru \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=righi.andrea@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®