Re: 3.2.0-rc2+git: possible recursive locking detected in processmemory freeing

[Cong Wang]

On Wed, Nov 23, 2011 at 7:12 PM, Meelis Roos <mroos@xxxxxxxx> wrote:
> This is 3.2.0-rc2-00143-ga767835 kernel on Sun Fire V100 (64-bit sparc).
> It gives the locking warning on bootup but seems to work fine otherwise
> (apt-get dist-upgrade saw no problems). It did not happen on a very
> similar Netra X1 but the kernel conf might have been different there
> (have not verified).
[...]
> [ Â 90.626091] =============================================
> [ Â 90.697052] [ INFO: possible recursive locking detected ]
> [ Â 90.768027] 3.2.0-rc2-00143-ga767835 #8
> [ Â 90.818411] ---------------------------------------------
> [ Â 90.889387] 000resolvconf/921 is trying to acquire lock:
> [ Â 90.959210] Â(&(&parent->list_lock)->rlock){..-...}, at: [<000000000070a8ec>] cache_flusharray+0x14/0xc8
> [ Â 91.083911]
> [ Â 91.083917] but task is already holding lock:
> [ Â 91.160578] Â(&(&parent->list_lock)->rlock){..-...}, at: [<000000000070a8ec>] cache_flusharray+0x14/0xc8
> [ Â 91.285283]
> [ Â 91.285289] other info that might help us debug this:
> [ Â 91.371092] ÂPossible unsafe locking scenario:
> [ Â 91.371102]
> [ Â 91.448908] Â Â Â ÂCPU0
> [ Â 91.480915] Â Â Â Â----
> [ Â 91.512918] Â lock(&(&parent->list_lock)->rlock);
> [ Â 91.574632] Â lock(&(&parent->list_lock)->rlock);
> [ Â 91.636353]
> [ Â 91.636359] Â*** DEADLOCK ***
> [ Â 91.636367]
> [ Â 91.714182] ÂMay be due to missing lock nesting notation
> [ Â 91.714193]
> [ Â 91.803440] 1 lock held by 000resolvconf/921:
> [ Â 91.860594] Â#0: Â(&(&parent->list_lock)->rlock){..-...}, at: [<000000000070a8ec>] cache_flusharray+0x14/0xc8
> [ Â 91.990909]
> [ Â 91.990916] stack backtrace:
> [ Â 92.048140] Call Trace:
> [ Â 92.080167] Â[0000000000487c0c] __lock_acquire+0xfec/0x1d00
> [ Â 92.153419] Â[0000000000488e2c] lock_acquire+0x4c/0x80
> [ Â 92.220959] Â[000000000070f51c] _raw_spin_lock+0x1c/0x40
> [ Â 92.290780] Â[000000000070a8ec] cache_flusharray+0x14/0xc8
> [ Â 92.362897] Â[00000000004ccaa8] kmem_cache_free+0x88/0xa0
> [ Â 92.433859] Â[00000000004ccb04] slab_destroy+0x44/0x80
> [ Â 92.501397] Â[00000000004ccc8c] free_block+0x14c/0x180
> [ Â 92.568937] Â[000000000070a958] cache_flusharray+0x80/0xc8
> [ Â 92.641048] Â[00000000004ccaa8] kmem_cache_free+0x88/0xa0
> [ Â 92.712021] Â[00000000004b80d0] free_pgd_range+0x1f0/0x320
> [ Â 92.784126] Â[00000000004b828c] free_pgtables+0x8c/0xc0
> [ Â 92.852813] Â[00000000004bf2cc] exit_mmap+0xac/0x140
> [ Â 92.918065] Â[000000000045464c] mmput+0x2c/0x100
> [ Â 92.978745] Â[0000000000458958] exit_mm+0xf8/0x160
> [ Â 93.041710] Â[000000000045a790] do_exit+0xf0/0x7c0
> [ Â 93.104679] Â[000000000045b088] do_group_exit+0x28/0xc0

Seems we have a recursive call chain...

__cache_free()
-> cache_flusharray()
  -> free_block()
    -> slab_destroy()
      -> kmem_cache_free()
        -> __cache_free()

Cc Pekka.
--
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/