Bug 478583 - Possible circular locking dependencies detected in 2.6.29 series
Possible circular locking dependencies detected in 2.6.29 series
Status: CLOSED DUPLICATE of bug 481687
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-01 07:35 EST by James
Modified: 2009-02-27 08:43 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-27 08:43:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (36.48 KB, text/plain)
2009-01-01 07:35 EST, James
no flags Details
2.6.29git3 log (43.43 KB, text/plain)
2009-01-01 11:51 EST, Mateusz M.
no flags Details

  None (edit)
Description James 2009-01-01 07:35:33 EST
Created attachment 328034 [details]
dmesg output

Description of problem:
Message "possible circular locking dependency detected" appeared during graphical boot with vga=791 cmdline option. See attached dmesg output for more.

Version-Release number of selected component (if applicable):
kernel-2.6.29-0.7.rc0.git3.fc11.i686

How reproducible:
Always.

Steps to Reproduce:
1. Boot with vga=791 rhgb cmdline options.
  
Additional info:
This is on ATi Mobility Radion 9200 hardware (M9+).
Comment 1 Mateusz M. 2009-01-01 11:51:12 EST
Created attachment 328037 [details]
2.6.29git3 log
Comment 2 Ronald Warsow 2009-01-11 23:18:08 EST
got this one

...

hda-intel: Invalid position buffer, using LPIB read method instead.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-0.25.rc0.git14.fc11.i686 #1
-------------------------------------------------------
pulseaudio/2686 is trying to acquire lock:
 (&pcm->open_mutex){--..}, at: [<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]

but task is already holding lock:
 (&mm->mmap_sem){----}, at: [<c0493c6b>] sys_munmap+0x23/0x3f

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (&mm->mmap_sem){----}:
       [<c044feaf>] __lock_acquire+0x9af/0xb22
       [<c045007d>] lock_acquire+0x5b/0x81
       [<c048dfe9>] might_fault+0x53/0x73
       [<f7ee8f24>] snd_hda_mixer_amp_tlv+0x33/0xad [snd_hda_codec]
       [<f7d1a2e4>] alc_cap_vol_tlv+0x45/0x59 [snd_hda_codec_realtek]
       [<f7da6bb0>] snd_ctl_tlv_ioctl+0xcc/0x131 [snd]
       [<f7da8177>] snd_ctl_ioctl+0xb0c/0xcd0 [snd]
       [<c04b0e93>] vfs_ioctl+0x22/0x69
       [<c04b1367>] do_vfs_ioctl+0x3c9/0x3f3
       [<c04b13d1>] sys_ioctl+0x40/0x5a
       [<c0403b76>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #2 (&codec->spdif_mutex){--..}:
       [<c044feaf>] __lock_acquire+0x9af/0xb22
       [<c045007d>] lock_acquire+0x5b/0x81
       [<c06e16f8>] __mutex_lock_common+0xd5/0x329
       [<c06e19e4>] mutex_lock_nested+0x2e/0x36
       [<f7ee7516>] snd_hda_multi_out_analog_open+0x9b/0xed [snd_hda_codec]
       [<f7d15ff0>] alc880_playback_pcm_open+0x14/0x19 [snd_hda_codec_realtek]
       [<f7f02639>] azx_pcm_open+0x13c/0x1a7 [snd_hda_intel]
       [<f7df6185>] snd_pcm_open_substream+0x46/0x97 [snd_pcm]
       [<f7df627c>] snd_pcm_open+0xa6/0x182 [snd_pcm]
       [<f7df63a4>] snd_pcm_playback_open+0x23/0x26 [snd_pcm]
       [<f7da44db>] snd_open+0xd2/0x12f [snd]
       [<c04a9244>] chrdev_open+0x124/0x13b
       [<c04a55a0>] __dentry_open+0x168/0x267
       [<c04a5739>] nameidata_to_filp+0x2c/0x43
       [<c04af681>] do_filp_open+0x35f/0x67b
       [<c04a5364>] do_sys_open+0x42/0xb7
       [<c04a541b>] sys_open+0x1e/0x26
       [<c0403b76>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #1 (&chip->open_mutex){--..}:
       [<c044feaf>] __lock_acquire+0x9af/0xb22
       [<c045007d>] lock_acquire+0x5b/0x81
       [<c06e16f8>] __mutex_lock_common+0xd5/0x329
       [<c06e19e4>] mutex_lock_nested+0x2e/0x36
       [<f7f02534>] azx_pcm_open+0x37/0x1a7 [snd_hda_intel]
       [<f7df6185>] snd_pcm_open_substream+0x46/0x97 [snd_pcm]
       [<f7df627c>] snd_pcm_open+0xa6/0x182 [snd_pcm]
       [<f7df63a4>] snd_pcm_playback_open+0x23/0x26 [snd_pcm]
       [<f7da44db>] snd_open+0xd2/0x12f [snd]
       [<c04a9244>] chrdev_open+0x124/0x13b
       [<c04a55a0>] __dentry_open+0x168/0x267
       [<c04a5739>] nameidata_to_filp+0x2c/0x43
       [<c04af681>] do_filp_open+0x35f/0x67b
       [<c04a5364>] do_sys_open+0x42/0xb7
       [<c04a541b>] sys_open+0x1e/0x26
       [<c0403b76>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #0 (&pcm->open_mutex){--..}:
       [<c044fd84>] __lock_acquire+0x884/0xb22
       [<c045007d>] lock_acquire+0x5b/0x81
       [<c06e16f8>] __mutex_lock_common+0xd5/0x329
       [<c06e19e4>] mutex_lock_nested+0x2e/0x36
       [<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]
       [<c04a7b2a>] __fput+0xcf/0x15f
       [<c04a7bd3>] fput+0x19/0x1b
       [<c0492e81>] remove_vma+0x3c/0x5b
       [<c0493c2d>] do_munmap+0x21c/0x237
       [<c0493c78>] sys_munmap+0x30/0x3f
       [<c0403b76>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

1 lock held by pulseaudio/2686:
 #0:  (&mm->mmap_sem){----}, at: [<c0493c6b>] sys_munmap+0x23/0x3f

stack backtrace:
Pid: 2686, comm: pulseaudio Not tainted 2.6.29-0.25.rc0.git14.fc11.i686 #1
Call Trace:
 [<c06e0513>] ? printk+0xf/0x14
 [<c044f2e9>] print_circular_bug_tail+0x5d/0x68
 [<c044fd84>] __lock_acquire+0x884/0xb22
 [<c045007d>] lock_acquire+0x5b/0x81
 [<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
 [<c06e16f8>] __mutex_lock_common+0xd5/0x329
 [<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
 [<c044d7d7>] ? lock_release_holdtime+0x30/0x131
 [<c049331b>] ? unlink_file_vma+0x73/0x79
 [<c06e19e4>] mutex_lock_nested+0x2e/0x36
 [<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
 [<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]
 [<c04a7b2a>] __fput+0xcf/0x15f
 [<c04a7bd3>] fput+0x19/0x1b
 [<c0492e81>] remove_vma+0x3c/0x5b
 [<c0493c2d>] do_munmap+0x21c/0x237
 [<c0493c78>] sys_munmap+0x30/0x3f
 [<c0403b76>] syscall_call+0x7/0xb
Comment 3 James 2009-01-27 15:53:36 EST
Seen another one, this on 2.6.29-0.53.rc2.git1.fc11.x86_64:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-0.53.rc2.git1.fc11.x86_64 #1
-------------------------------------------------------
flurry/4259 is trying to acquire lock:
 (&mm->mmap_sem){----}, at: [<ffffffff810ba071>] might_fault+0x5d/0xb1

but task is already holding lock:
 (&dev->struct_mutex){--..}, at: [<ffffffffa03b7da1>] i915_gem_execbuffer+0x139/0xb2a [i915]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&dev->struct_mutex){--..}:
       [<ffffffff8106e95d>] __lock_acquire+0xaab/0xc41
       [<ffffffff8106eb80>] lock_acquire+0x8d/0xba
       [<ffffffff813818aa>] __mutex_lock_common+0x107/0x39c
       [<ffffffff81381be8>] mutex_lock_nested+0x35/0x3a
       [<ffffffffa0387bf0>] drm_vm_open+0x31/0x46 [drm]
       [<ffffffff8104860c>] dup_mm+0x2e6/0x3cc
       [<ffffffff810492b0>] copy_process+0xb82/0x136d
       [<ffffffff81049bfb>] do_fork+0x160/0x31f
       [<ffffffff8100f62d>] sys_clone+0x23/0x25
       [<ffffffff810117c3>] stub_clone+0x13/0x20
       [<ffffffffffffffff>] 0xffffffffffffffff

-> #1 (&mm->mmap_sem/1){--..}:
       [<ffffffff8106e95d>] __lock_acquire+0xaab/0xc41
       [<ffffffff8106eb80>] lock_acquire+0x8d/0xba
       [<ffffffff8106234a>] down_write_nested+0x4b/0x7f
       [<ffffffff810483f5>] dup_mm+0xcf/0x3cc
       [<ffffffff810492b0>] copy_process+0xb82/0x136d
       [<ffffffff81049bfb>] do_fork+0x160/0x31f
       [<ffffffff8100f62d>] sys_clone+0x23/0x25
       [<ffffffff810117c3>] stub_clone+0x13/0x20
       [<ffffffffffffffff>] 0xffffffffffffffff

-> #0 (&mm->mmap_sem){----}:
       [<ffffffff8106e7fe>] __lock_acquire+0x94c/0xc41
       [<ffffffff8106eb80>] lock_acquire+0x8d/0xba
       [<ffffffff810ba09e>] might_fault+0x8a/0xb1
       [<ffffffffa03b27f8>] i915_emit_box+0x2f/0x259 [i915]
       [<ffffffffa03b83db>] i915_gem_execbuffer+0x773/0xb2a [i915]
       [<ffffffffa0381e59>] drm_ioctl+0x1e6/0x271 [drm]
       [<ffffffff810eab55>] vfs_ioctl+0x5f/0x78
       [<ffffffff810eafd9>] do_vfs_ioctl+0x46b/0x4ab
       [<ffffffff810eb06e>] sys_ioctl+0x55/0x77
       [<ffffffff810112ba>] system_call_fastpath+0x16/0x1b
       [<ffffffffffffffff>] 0xffffffffffffffff

other info that might help us debug this:

1 lock held by flurry/4259:
 #0:  (&dev->struct_mutex){--..}, at: [<ffffffffa03b7da1>] i915_gem_execbuffer+0x139/0xb2a [i915]

stack backtrace:
Pid: 4259, comm: flurry Not tainted 2.6.29-0.53.rc2.git1.fc11.x86_64 #1
Call Trace:
 [<ffffffff8106dc01>] print_circular_bug_tail+0x71/0x7c
 [<ffffffff8106e7fe>] __lock_acquire+0x94c/0xc41
 [<ffffffff8106eb80>] lock_acquire+0x8d/0xba
 [<ffffffff810ba071>] ? might_fault+0x5d/0xb1
 [<ffffffff810ba09e>] might_fault+0x8a/0xb1
 [<ffffffff810ba071>] ? might_fault+0x5d/0xb1
 [<ffffffffa03b27f8>] i915_emit_box+0x2f/0x259 [i915]
 [<ffffffffa03b83db>] i915_gem_execbuffer+0x773/0xb2a [i915]
 [<ffffffffa0381e1f>] ? drm_ioctl+0x1ac/0x271 [drm]
 [<ffffffffa0381e59>] drm_ioctl+0x1e6/0x271 [drm]
 [<ffffffff8119a5cc>] ? _raw_spin_lock+0x68/0x116
 [<ffffffffa03b7c68>] ? i915_gem_execbuffer+0x0/0xb2a [i915]
 [<ffffffff810eab55>] vfs_ioctl+0x5f/0x78
 [<ffffffff81383055>] ? _spin_unlock_irqrestore+0x47/0x57
 [<ffffffff810eafd9>] do_vfs_ioctl+0x46b/0x4ab
 [<ffffffff810eb06e>] sys_ioctl+0x55/0x77
 [<ffffffff810112ba>] system_call_fastpath+0x16/0x1b
Comment 4 James 2009-01-30 04:32:06 EST
Still present in 2.6.29-0.64.rc3.fc11.x86_64. To clarify, the first trace I submitted was on a machine with a Radeon 9200 graphics chip; the one from Comment #3 is from a different machine with Intel X3100 graphics and can be provoked by running a GL app; Comment #2 appears to have a CLD in the sound driver. Are we all seeing the same bug here, or similar manifestations of separate bugs?
Comment 5 James 2009-02-12 05:02:20 EST
I've not seen this in 2.6.29-0.20.rc3.git12.fc10.x86_64, anyone want to chime in or should I close this?
Comment 6 Ronald Warsow 2009-02-26 22:51:06 EST
same here as in #5
Comment 7 Kyle McMartin 2009-02-27 08:43:17 EST

*** This bug has been marked as a duplicate of bug 481687 ***

Note You need to log in before you can comment on or make changes to this bug.