1. 31 May, 2016 1 commit
  2. 25 May, 2016 2 commits
  3. 06 May, 2016 5 commits
    • Anand Jain's avatar
      btrfs: fix lock dep warning move scratch super outside of chunk_mutex · 48b3b9d4
      Anand Jain authored
      Move scratch super outside of the chunk lock to avoid below
      lockdep warning. The better place to scratch super is in
      the function btrfs_rm_dev_replace_free_srcdev() just before
      free_device, which is outside of the chunk lock as well.
      
      To reproduce:
        (fresh boot)
        mkfs.btrfs -f -draid5 -mraid5 /dev/sdc /dev/sdd /dev/sde
        mount /dev/sdc /btrfs
        dd if=/dev/zero of=/btrfs/tf1 bs=4096 count=100
        (get devmgt from https://github.com/asj/devmgt.git
      
      )
        devmgt detach /dev/sde
        dd if=/dev/zero of=/btrfs/tf1 bs=4096 count=100
        sync
        btrfs replace start -Brf 3 /dev/sdf /btrfs <--
        devmgt attach host7
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      4.6.0-rc2asj+ #1 Not tainted
      ---------------------------------------------------
      
      btrfs/2174 is trying to acquire lock:
      (sb_writers){.+.+.+}, at:
      [<ffffffff812449b4>] __sb_start_write+0xb4/0xf0
      
      but task is already holding lock:
      (&fs_info->chunk_mutex){+.+.+.}, at:
      [<ffffffffa05c5f55>] btrfs_dev_replace_finishing+0x145/0x980 [btrfs]
      
      which lock already depends on the new lock.
      
      Chain exists of:
      sb_writers --> &fs_devs->device_list_mutex --> &fs_info->chunk_mutex
      Possible unsafe locking scenario:
      CPU0				CPU1
      ----				----
      lock(&fs_info->chunk_mutex);
      				lock(&fs_devs->device_list_mutex);
      				lock(&fs_info->chunk_mutex);
      lock(sb_writers);
      
      *** DEADLOCK ***
      
      -> #0 (sb_writers){.+.+.+}:
      [<ffffffff810e6415>] __lock_acquire+0x1bc5/0x1ee0
      [<ffffffff810e707e>] lock_acquire+0xbe/0x210
      [<ffffffff810df49a>] percpu_down_read+0x4a/0xa0
      [<ffffffff812449b4>] __sb_start_write+0xb4/0xf0
      [<ffffffff81265534>] mnt_want_write+0x24/0x50
      [<ffffffff812508a2>] path_openat+0x952/0x1190
      [<ffffffff81252451>] do_filp_open+0x91/0x100
      [<ffffffff8123f5cc>] file_open_name+0xfc/0x140
      [<ffffffff8123f643>] filp_open+0x33/0x60
      [<ffffffffa0572bb6>] update_dev_time+0x16/0x40 [btrfs]
      [<ffffffffa057f60d>] btrfs_scratch_superblocks+0x5d/0xb0 [btrfs]
      [<ffffffffa057f70e>] btrfs_rm_dev_replace_remove_srcdev+0xae/0xd0 [btrfs]
      [<ffffffffa05c62c5>] btrfs_dev_replace_finishing+0x4b5/0x980 [btrfs]
      [<ffffffffa05c6ae8>] btrfs_dev_replace_start+0x358/0x530 [btrfs]
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      48b3b9d4
    • Josef Bacik's avatar
      Btrfs: remove BUG_ON()'s in btrfs_map_block · e042d1ec
      Josef Bacik authored
      
      
      btrfs_map_block can go horribly wrong in the face of fs corruption, lets agree
      to not be assholes and panic at any possible chance things are all fucked up.
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      [ removed type casts ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      e042d1ec
    • Liu Bo's avatar
      Btrfs: fix divide error upon chunk's stripe_len · 3d8da678
      Liu Bo authored
      
      
      The struct 'map_lookup' uses type int for @stripe_len, while
      btrfs_chunk_stripe_len() can return a u64 value, and it may end up with
      @stripe_len being undefined value and it can lead to 'divide error' in
       __btrfs_map_block().
      
      This changes 'map_lookup' to use type u64 for stripe_len, also right now
      we only use BTRFS_STRIPE_LEN for stripe_len, so this adds a valid checker for
      BTRFS_STRIPE_LEN.
      Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Reported-by: default avatarQuentin Casasnovas <quentin.casasnovas@oracle.com>
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ folded division fix to scrub_raid56_parity ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      3d8da678
    • Anand Jain's avatar
      btrfs: fix lock dep warning, move scratch dev out of device_list_mutex and uuid_mutex · 779bf3fe
      Anand Jain authored
      
      
      When the replace target fails, the target device will be taken
      out of fs device list, scratch + update_dev_time and freed. However
      we could do the scratch  + update_dev_time and free part after the
      device has been taken out of device list, so that we don't have to
      hold the device_list_mutex and uuid_mutex locks.
      
      Reported issue:
      
      [ 5375.718845] ======================================================
      [ 5375.718846] [ INFO: possible circular locking dependency detected ]
      [ 5375.718849] 4.4.5-scst31x-debug-11+ #40 Not tainted
      [ 5375.718849] -------------------------------------------------------
      [ 5375.718851] btrfs-health/4662 is trying to acquire lock:
      [ 5375.718861]  (sb_writers){.+.+.+}, at: [<ffffffff812214f7>] __sb_start_write+0xb7/0xf0
      [ 5375.718862]
      [ 5375.718862] but task is already holding lock:
      [ 5375.718907]  (&fs_devs->device_list_mutex){+.+.+.}, at: [<ffffffffa028263c>] btrfs_destroy_dev_replace_tgtdev+0x3c/0x150 [btrfs]
      [ 5375.718907]
      [ 5375.718907] which lock already depends on the new lock.
      [ 5375.718907]
      [ 5375.718908]
      [ 5375.718908] the existing dependency chain (in reverse order) is:
      [ 5375.718911]
      [ 5375.718911] -> #3 (&fs_devs->device_list_mutex){+.+.+.}:
      [ 5375.718917]        [<ffffffff810da4be>] lock_acquire+0xce/0x1e0
      [ 5375.718921]        [<ffffffff81633949>] mutex_lock_nested+0x69/0x3c0
      [ 5375.718940]        [<ffffffffa0219bf6>] btrfs_show_devname+0x36/0x210 [btrfs]
      [ 5375.718945]        [<ffffffff81267079>] show_vfsmnt+0x49/0x150
      [ 5375.718948]        [<ffffffff81240b07>] m_show+0x17/0x20
      [ 5375.718951]        [<ffffffff81246868>] seq_read+0x2d8/0x3b0
      [ 5375.718955]        [<ffffffff8121df28>] __vfs_read+0x28/0xd0
      [ 5375.718959]        [<ffffffff8121e806>] vfs_read+0x86/0x130
      [ 5375.718962]        [<ffffffff8121f4c9>] SyS_read+0x49/0xa0
      [ 5375.718966]        [<ffffffff81637976>] entry_SYSCALL_64_fastpath+0x16/0x7a
      [ 5375.718968]
      [ 5375.718968] -> #2 (namespace_sem){+++++.}:
      [ 5375.718971]        [<ffffffff810da4be>] lock_acquire+0xce/0x1e0
      [ 5375.718974]        [<ffffffff81635199>] down_write+0x49/0x80
      [ 5375.718977]        [<ffffffff81243593>] lock_mount+0x43/0x1c0
      [ 5375.718979]        [<ffffffff81243c13>] do_add_mount+0x23/0xd0
      [ 5375.718982]        [<ffffffff81244afb>] do_mount+0x27b/0xe30
      [ 5375.718985]        [<ffffffff812459dc>] SyS_mount+0x8c/0xd0
      [ 5375.718988]        [<ffffffff81637976>] entry_SYSCALL_64_fastpath+0x16/0x7a
      [ 5375.718991]
      [ 5375.718991] -> #1 (&sb->s_type->i_mutex_key#5){+.+.+.}:
      [ 5375.718994]        [<ffffffff810da4be>] lock_acquire+0xce/0x1e0
      [ 5375.718996]        [<ffffffff81633949>] mutex_lock_nested+0x69/0x3c0
      [ 5375.719001]        [<ffffffff8122d608>] path_openat+0x468/0x1360
      [ 5375.719004]        [<ffffffff8122f86e>] do_filp_open+0x7e/0xe0
      [ 5375.719007]        [<ffffffff8121da7b>] do_sys_open+0x12b/0x210
      [ 5375.719010]        [<ffffffff8121db7e>] SyS_open+0x1e/0x20
      [ 5375.719013]        [<ffffffff81637976>] entry_SYSCALL_64_fastpath+0x16/0x7a
      [ 5375.719015]
      [ 5375.719015] -> #0 (sb_writers){.+.+.+}:
      [ 5375.719018]        [<ffffffff810d97ca>] __lock_acquire+0x17ba/0x1ae0
      [ 5375.719021]        [<ffffffff810da4be>] lock_acquire+0xce/0x1e0
      [ 5375.719026]        [<ffffffff810d3bef>] percpu_down_read+0x4f/0xa0
      [ 5375.719028]        [<ffffffff812214f7>] __sb_start_write+0xb7/0xf0
      [ 5375.719031]        [<ffffffff81242eb4>] mnt_want_write+0x24/0x50
      [ 5375.719035]        [<ffffffff8122ded2>] path_openat+0xd32/0x1360
      [ 5375.719037]        [<ffffffff8122f86e>] do_filp_open+0x7e/0xe0
      [ 5375.719040]        [<ffffffff8121d8a4>] file_open_name+0xe4/0x130
      [ 5375.719043]        [<ffffffff8121d923>] filp_open+0x33/0x60
      [ 5375.719073]        [<ffffffffa02776a6>] update_dev_time+0x16/0x40 [btrfs]
      [ 5375.719099]        [<ffffffffa02825be>] btrfs_scratch_superblocks+0x4e/0x90 [btrfs]
      [ 5375.719123]        [<ffffffffa0282665>] btrfs_destroy_dev_replace_tgtdev+0x65/0x150 [btrfs]
      [ 5375.719150]        [<ffffffffa02c6c80>] btrfs_dev_replace_finishing+0x6b0/0x990 [btrfs]
      [ 5375.719175]        [<ffffffffa02c729e>] btrfs_dev_replace_start+0x33e/0x540 [btrfs]
      [ 5375.719199]        [<ffffffffa02c7f58>] btrfs_auto_replace_start+0xf8/0x140 [btrfs]
      [ 5375.719222]        [<ffffffffa02464e6>] health_kthread+0x246/0x490 [btrfs]
      [ 5375.719225]        [<ffffffff810a70df>] kthread+0xef/0x110
      [ 5375.719229]        [<ffffffff81637d2f>] ret_from_fork+0x3f/0x70
      [ 5375.719230]
      [ 5375.719230] other info that might help us debug this:
      [ 5375.719230]
      [ 5375.719233] Chain exists of:
      [ 5375.719233]   sb_writers --> namespace_sem --> &fs_devs->device_list_mutex
      [ 5375.719233]
      [ 5375.719234]  Possible unsafe locking scenario:
      [ 5375.719234]
      [ 5375.719234]        CPU0                    CPU1
      [ 5375.719235]        ----                    ----
      [ 5375.719236]   lock(&fs_devs->device_list_mutex);
      [ 5375.719238]                                lock(namespace_sem);
      [ 5375.719239]                                lock(&fs_devs->device_list_mutex);
      [ 5375.719241]   lock(sb_writers);
      [ 5375.719241]
      [ 5375.719241]  *** DEADLOCK ***
      [ 5375.719241]
      [ 5375.719243] 4 locks held by btrfs-health/4662:
      [ 5375.719266]  #0:  (&fs_info->health_mutex){+.+.+.}, at: [<ffffffffa0246303>] health_kthread+0x63/0x490 [btrfs]
      [ 5375.719293]  #1:  (&fs_info->dev_replace.lock_finishing_cancel_unmount){+.+.+.}, at: [<ffffffffa02c6611>] btrfs_dev_replace_finishing+0x41/0x990 [btrfs]
      [ 5375.719319]  #2:  (uuid_mutex){+.+.+.}, at: [<ffffffffa0282620>] btrfs_destroy_dev_replace_tgtdev+0x20/0x150 [btrfs]
      [ 5375.719343]  #3:  (&fs_devs->device_list_mutex){+.+.+.}, at: [<ffffffffa028263c>] btrfs_destroy_dev_replace_tgtdev+0x3c/0x150 [btrfs]
      [ 5375.719343]
      [ 5375.719343] stack backtrace:
      [ 5375.719347] CPU: 2 PID: 4662 Comm: btrfs-health Not tainted 4.4.5-scst31x-debug-11+ #40
      [ 5375.719348] Hardware name: Supermicro SYS-6018R-WTRT/X10DRW-iT, BIOS 1.0c 01/07/2015
      [ 5375.719352]  0000000000000000 ffff880856f73880 ffffffff813529e3 ffffffff826182a0
      [ 5375.719354]  ffffffff8260c090 ffff880856f738c0 ffffffff810d667c ffff880856f73930
      [ 5375.719357]  ffff880861f32b40 ffff880861f32b68 0000000000000003 0000000000000004
      [ 5375.719357] Call Trace:
      [ 5375.719363]  [<ffffffff813529e3>] dump_stack+0x85/0xc2
      [ 5375.719366]  [<ffffffff810d667c>] print_circular_bug+0x1ec/0x260
      [ 5375.719369]  [<ffffffff810d97ca>] __lock_acquire+0x17ba/0x1ae0
      [ 5375.719373]  [<ffffffff810f606d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
      [ 5375.719376]  [<ffffffff810da4be>] lock_acquire+0xce/0x1e0
      [ 5375.719378]  [<ffffffff812214f7>] ? __sb_start_write+0xb7/0xf0
      [ 5375.719383]  [<ffffffff810d3bef>] percpu_down_read+0x4f/0xa0
      [ 5375.719385]  [<ffffffff812214f7>] ? __sb_start_write+0xb7/0xf0
      [ 5375.719387]  [<ffffffff812214f7>] __sb_start_write+0xb7/0xf0
      [ 5375.719389]  [<ffffffff81242eb4>] mnt_want_write+0x24/0x50
      [ 5375.719393]  [<ffffffff8122ded2>] path_openat+0xd32/0x1360
      [ 5375.719415]  [<ffffffffa02462a0>] ? btrfs_congested_fn+0x180/0x180 [btrfs]
      [ 5375.719418]  [<ffffffff810f606d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
      [ 5375.719420]  [<ffffffff8122f86e>] do_filp_open+0x7e/0xe0
      [ 5375.719423]  [<ffffffff810f615d>] ? rcu_read_lock_sched_held+0x6d/0x80
      [ 5375.719426]  [<ffffffff81201a9b>] ? kmem_cache_alloc+0x26b/0x5d0
      [ 5375.719430]  [<ffffffff8122e7d4>] ? getname_kernel+0x34/0x120
      [ 5375.719433]  [<ffffffff8121d8a4>] file_open_name+0xe4/0x130
      [ 5375.719436]  [<ffffffff8121d923>] filp_open+0x33/0x60
      [ 5375.719462]  [<ffffffffa02776a6>] update_dev_time+0x16/0x40 [btrfs]
      [ 5375.719485]  [<ffffffffa02825be>] btrfs_scratch_superblocks+0x4e/0x90 [btrfs]
      [ 5375.719506]  [<ffffffffa0282665>] btrfs_destroy_dev_replace_tgtdev+0x65/0x150 [btrfs]
      [ 5375.719530]  [<ffffffffa02c6c80>] btrfs_dev_replace_finishing+0x6b0/0x990 [btrfs]
      [ 5375.719554]  [<ffffffffa02c6b23>] ? btrfs_dev_replace_finishing+0x553/0x990 [btrfs]
      [ 5375.719576]  [<ffffffffa02c729e>] btrfs_dev_replace_start+0x33e/0x540 [btrfs]
      [ 5375.719598]  [<ffffffffa02c7f58>] btrfs_auto_replace_start+0xf8/0x140 [btrfs]
      [ 5375.719621]  [<ffffffffa02464e6>] health_kthread+0x246/0x490 [btrfs]
      [ 5375.719641]  [<ffffffffa02463d8>] ? health_kthread+0x138/0x490 [btrfs]
      [ 5375.719661]  [<ffffffffa02462a0>] ? btrfs_congested_fn+0x180/0x180 [btrfs]
      [ 5375.719663]  [<ffffffff810a70df>] kthread+0xef/0x110
      [ 5375.719666]  [<ffffffff810a6ff0>] ? kthread_create_on_node+0x200/0x200
      [ 5375.719669]  [<ffffffff81637d2f>] ret_from_fork+0x3f/0x70
      [ 5375.719672]  [<ffffffff810a6ff0>] ? kthread_create_on_node+0x200/0x200
      [ 5375.719697] ------------[ cut here ]------------
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      Reported-by: default avatarYauhen Kharuzhy <yauhen.kharuzhy@zavadatar.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      779bf3fe
    • Austin S. Hemmelgarn's avatar
      btrfs: allow balancing to dup with multi-device · 88be159c
      Austin S. Hemmelgarn authored
      
      
      Currently, we don't allow the user to try and rebalance to a dup profile
      on a multi-device filesystem.  In most cases, this is a perfectly sensible
      restriction as raid1 uses the same amount of space and provides better
      protection.
      
      However, when reshaping a multi-device filesystem down to a single device
      filesystem, this requires the user to convert metadata and system chunks
      to single profile before deleting devices, and then convert again to dup,
      which leaves a period of time where metadata integrity is reduced.
      
      This patch removes the single-device-only restriction from converting to
      dup profile to remove this potential data integrity reduction.
      Signed-off-by: default avatarAustin S. Hemmelgarn <ahferroin7@gmail.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      88be159c
  4. 04 May, 2016 2 commits
  5. 28 Apr, 2016 16 commits
  6. 04 Apr, 2016 1 commit
    • Kirill A. Shutemov's avatar
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov authored
      
      
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  7. 14 Mar, 2016 1 commit
  8. 23 Feb, 2016 1 commit
    • Liu Bo's avatar
      Btrfs: fix lockdep deadlock warning due to dev_replace · 73beece9
      Liu Bo authored
      Xfstests btrfs/011 complains about a deadlock warning,
      
      [ 1226.649039] =========================================================
      [ 1226.649039] [ INFO: possible irq lock inversion dependency detected ]
      [ 1226.649039] 4.1.0+ #270 Not tainted
      [ 1226.649039] ---------------------------------------------------------
      [ 1226.652955] kswapd0/46 just changed the state of lock:
      [ 1226.652955]  (&delayed_node->mutex){+.+.-.}, at: [<ffffffff81458735>] __btrfs_release_delayed_node+0x45/0x1d0
      [ 1226.652955] but this lock took another, RECLAIM_FS-unsafe lock in the past:
      [ 1226.652955]  (&fs_info->dev_replace.lock){+.+.+.}
      
      and interrupts could create inverse lock ordering between them.
      
      [ 1226.652955]
      other info that might help us debug this:
      [ 1226.652955] Chain exists of:
        &delayed_node->mutex --> &found->groups_sem --> &fs_info->dev_replace.lock
      
      [ 1226.652955]  Possible interrupt unsafe locking scenario:
      
      [ 1226.652955]        CPU0                    CPU1
      [ 1226.652955]        ----                    ----
      [ 1226.652955]   lock(&fs_info->dev_replace.lock);
      [ 1226.652955]                                local_irq_disable();
      [ 1226.652955]                                lock(&delayed_node->mutex);
      [ 1226.652955]                                lock(&found->groups_sem);
      [ 1226.652955]   <Interrupt>
      [ 1226.652955]     lock(&delayed_node->mutex);
      [ 1226.652955]
       *** DEADLOCK ***
      
      Commit 084b6e7c
      
       ("btrfs: Fix a lockdep warning when running xfstest.") tried
      to fix a similar one that has the exactly same warning, but with that, we still
      run to this.
      
      The above lock chain comes from
      btrfs_commit_transaction
        ->btrfs_run_delayed_items
          ...
          ->__btrfs_update_delayed_inode
            ...
            ->__btrfs_cow_block
               ...
               ->find_free_extent
                  ->cache_block_group
                    ->load_free_space_cache
                      ->btrfs_readpages
                        ->submit_one_bio
                          ...
                          ->__btrfs_map_block
                            ->btrfs_dev_replace_lock
      
      However, with high memory pressure, tasks which hold dev_replace.lock can
      be interrupted by kswapd and then kswapd is intended to release memory occupied
      by superblock, inodes and dentries, where we may call evict_inode, and it comes
      to
      
      [ 1226.652955]  [<ffffffff81458735>] __btrfs_release_delayed_node+0x45/0x1d0
      [ 1226.652955]  [<ffffffff81459e74>] btrfs_remove_delayed_node+0x24/0x30
      [ 1226.652955]  [<ffffffff8140c5fe>] btrfs_evict_inode+0x34e/0x700
      
      delayed_node->mutex may be acquired in __btrfs_release_delayed_node(), and it leads
      to a ABBA deadlock.
      
      To fix this, we can use "blocking rwlock" used in the case of extent_buffer, but
      things are simpler here since we only needs read's spinlock to blocking lock.
      
      With this, btrfs/011 no more produces warnings in dmesg.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      73beece9
  9. 11 Feb, 2016 3 commits
  10. 29 Jan, 2016 1 commit
  11. 21 Jan, 2016 1 commit
  12. 19 Jan, 2016 5 commits
  13. 15 Jan, 2016 1 commit