Had this pop up sometime in the last 24 hours but it didn't seem to
cause me any problems? Thought I'd pass it along if its of use or ignore
them in the future? I've attached the full dmesg output also.
[20653.098044] =========================================================
[20653.098044] [ INFO: possible irq lock inversion dependency detected ]
[20653.098044] 3.19.8 #6 Tainted: G O
[20653.098044] ---------------------------------------------------------
[20653.098044] kswapd0/513 just changed the state of lock:
[20653.098044] (&xfs_dir_ilock_class){++++-+}, at: [<ffffffff812f4360>]
xfs_ilock+0xb0/0x130
[20653.098044] but this lock took another, RECLAIM_FS-unsafe lock in the
past:
[20653.098044] (&mm->mmap_sem){++++++}
and interrupts could create inverse lock ordering
between them.
[20653.098044]
other info that might help us debug this:
[20653.098044] Possible interrupt unsafe locking scenario:
[20653.098044] CPU0 CPU1
[20653.098044] ---- ----
[20653.098044] lock(&mm->mmap_sem);
[20653.098044] local_irq_disable();
[20653.098044] lock(&xfs_dir_ilock_class);
[20653.098044] lock(&mm->mmap_sem);
[20653.098044] <Interrupt>
[20653.098044] lock(&xfs_dir_ilock_class);
[20653.098044]
*** DEADLOCK ***
[20653.098044] 3 locks held by kswapd0/513:
[20653.098044] #0: (shrinker_rwsem){++++..}, at: [<ffffffff811303d3>]
shrink_node_slabs+0x43/0x3b0
[20653.098044] #1: (&type->s_umount_key#36){.+.+.+}, at:
[<ffffffff8117b98f>] grab_super_passive+0x3f/0x90
[20653.098044] #2: (&pag->pag_ici_reclaim_lock){+.+...}, at:
[<ffffffff812eca52>] xfs_reclaim_inodes_ag+0xa2/0x3c0
[20653.214021]
the shortest dependencies between 2nd lock and 1st lock:
[20653.214021] -> (&mm->mmap_sem){++++++} ops: 1132789158 {
[20653.214021] HARDIRQ-ON-W at:
[20653.214021] [<ffffffff81092c43>]
__lock_acquire+0x9a3/0x2090
[20653.214021] [<ffffffff81095323>]
lock_acquire+0xc3/0x170
[20653.214021] [<ffffffff816d98c5>]
down_write+0x55/0xc0
[20653.214021] [<ffffffff8117fb50>]
do_execveat_common.isra.33+0x2e0/0x7a0
aug20_dmes_xfs_irq
Description: Text document
|