Skip to content
  • Liu Bo's avatar
    Btrfs: fix a lockdep warning when cleaning up aborted transaction · a9d2d4ad
    Liu Bo authored
    
    
    Given now we have 2 spinlock for management of delayed refs,
    CONFIG_DEBUG_SPINLOCK=y helped me find this,
    
    [ 4723.413809] BUG: spinlock wrong CPU on CPU#1, btrfs-transacti/2258
    [ 4723.414882]  lock: 0xffff880048377670, .magic: dead4ead, .owner: btrfs-transacti/2258, .owner_cpu: 2
    [ 4723.417146] CPU: 1 PID: 2258 Comm: btrfs-transacti Tainted: G        W  O 3.12.0+ #4
    [ 4723.421321] Call Trace:
    [ 4723.421872]  [<ffffffff81680fe7>] dump_stack+0x54/0x74
    [ 4723.422753]  [<ffffffff81681093>] spin_dump+0x8c/0x91
    [ 4723.424979]  [<ffffffff816810b9>] spin_bug+0x21/0x26
    [ 4723.425846]  [<ffffffff81323956>] do_raw_spin_unlock+0x66/0x90
    [ 4723.434424]  [<ffffffff81689bf7>] _raw_spin_unlock+0x27/0x40
    [ 4723.438747]  [<ffffffffa015da9e>] btrfs_cleanup_one_transaction+0x35e/0x710 [btrfs]
    [ 4723.443321]  [<ffffffffa015df54>] btrfs_cleanup_transaction+0x104/0x570 [btrfs]
    [ 4723.444692]  [<ffffffff810c1b5d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
    [ 4723.450336]  [<ffffffff810c1c2d>] ? trace_hardirqs_on+0xd/0x10
    [ 4723.451332]  [<ffffffffa015e5ee>] transaction_kthread+0x22e/0x270 [btrfs]
    [ 4723.452543]  [<ffffffffa015e3c0>] ? btrfs_cleanup_transaction+0x570/0x570 [btrfs]
    [ 4723.457833]  [<ffffffff81079efa>] kthread+0xea/0xf0
    [ 4723.458990]  [<ffffffff81079e10>] ? kthread_create_on_node+0x140/0x140
    [ 4723.460133]  [<ffffffff81692aac>] ret_from_fork+0x7c/0xb0
    [ 4723.460865]  [<ffffffff81079e10>] ? kthread_create_on_node+0x140/0x140
    [ 4723.496521] ------------[ cut here ]------------
    
    ----------------------------------------------------------------------
    
    The reason is that we get to call cond_resched_lock(&head_ref->lock) while
    still holding @delayed_refs->lock.
    
    So it's different with __btrfs_run_delayed_refs(), where we do drop-acquire
    dance before and after actually processing delayed refs.
    
    Here we don't drop the lock, others are not able to add new delayed refs to
    head_ref, so cond_resched_lock(&head_ref->lock) is not necessary here.
    
    Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
    Signed-off-by: default avatarChris Mason <clm@fb.com>
    a9d2d4ad