xfs
[Top] [All Lists]

3.7.0-rc7: possible irq lock inversion dependency detected

To: xfs@xxxxxxxxxxx
Subject: 3.7.0-rc7: possible irq lock inversion dependency detected
From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
Date: Fri, 21 Dec 2012 02:49:42 -0800 (PST)
User-agent: Alpine 2.01 (DEB 1266 2009-07-14)
Hi,

while still running 3.7.0-rc7 on this powerpc machine (32bit, G4), the 
message below was printed while the machine was fairly loaded (disk/cpu). 
The machine is still running fine, but I thought I should share this 
incident. Full dmesg & .config:

  http://nerdbynature.de/bits/3.7.0-rc7/

The kernel says "-dirty" because a patch for 
arch/powerpc/kernel/entry_32.S has been applied.

Christian.

[0] http://lkml.indiana.edu/hypermail/linux/kernel/1211.3/01917.html

 =========================================================
 [ INFO: possible irq lock inversion dependency detected ]
 3.7.0-rc7-dirty #1 Not tainted
 ---------------------------------------------------------
 kswapd0/237 just changed the state of lock:
  (sb_internal#2){.+.+.?}, at: [<c022c9e4>] xfs_trans_alloc+0x2c/0x60
 but this lock took another, RECLAIM_FS-unsafe lock in the past:
  (&(&ip->i_lock)->mr_lock/1){+.+.+.}
 
 and interrupts could create inverse lock ordering between them.
 
 
 other info that might help us debug this:
  Possible interrupt unsafe locking scenario:
 
        CPU0                    CPU1
        ----                    ----
   lock(&(&ip->i_lock)->mr_lock/1);
                                local_irq_disable();
                                lock(sb_internal#2);
                                lock(&(&ip->i_lock)->mr_lock/1);
   <Interrupt>
     lock(sb_internal#2);
 
  *** DEADLOCK ***
 
 2 locks held by kswapd0/237:
  #0:  (shrinker_rwsem){++++..}, at: [<c00ae100>] shrink_slab+0x78/0x324
  #1:  (&type->s_umount_key#31){++++++}, at: [<c00de6c0>] 
grab_super_passive+0x58/0xcc
[...] 

-- 
BOFH excuse #286:

Telecommunications is downgrading.

<Prev in Thread] Current Thread [Next in Thread>