1. 06 Mar, 2023 6 commits
    • Filipe Manana's avatar
      btrfs: fix extent map logging bit not cleared for split maps after dropping range · e4cc1483
      Filipe Manana authored
      At btrfs_drop_extent_map_range() we are clearing the EXTENT_FLAG_LOGGING
      bit on a 'flags' variable that was not initialized. This makes static
      checkers complain about it, so initialize the 'flags' variable before
      clearing the bit.
      
      In practice this has no consequences, because EXTENT_FLAG_LOGGING should
      not be set when btrfs_drop_extent_map_range() is called, as an fsync locks
      the inode in exclusive mode, locks the inode's mmap semaphore in exclusive
      mode too and it always flushes all delalloc.
      
      Also add a comment about why we clear EXTENT_FLAG_LOGGING on a copy of the
      flags of the split extent map.
      Reported-by: default avatarDan Carpenter <error27@gmail.com>
      Link: https://lore.kernel.org/linux-btrfs/Y%2FyipSVozUDEZKow@kili/
      Fixes: db21370b ("btrfs: drop extent map range more efficiently")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      e4cc1483
    • Johannes Thumshirn's avatar
      btrfs: fix percent calculation for bg reclaim message · 95cd356c
      Johannes Thumshirn authored
      We have a report, that the info message for block-group reclaim is
      crossing the 100% used mark.
      
      This is happening as we were truncating the divisor for the division
      (the block_group->length) to a 32bit value.
      
      Fix this by using div64_u64() to not truncate the divisor.
      
      In the worst case, it can lead to a div by zero error and should be
      possible to trigger on 4 disks RAID0, and each device is large enough:
      
        $ mkfs.btrfs  -f /dev/test/scratch[1234] -m raid1 -d raid0
        btrfs-progs v6.1
        [...]
        Filesystem size:    40.00GiB
        Block group profiles:
          Data:             RAID0             4.00GiB <<<
          Metadata:         RAID1           256.00MiB
          System:           RAID1             8.00MiB
      Reported-by: default avatarForza <forza@tnonline.net>
      Link: https://lore.kernel.org/linux-btrfs/e99483.c11a58d.1863591ca52@tnonline.net/
      Fixes: 5f93e776 ("btrfs: zoned: print unusable percentage when reclaiming block groups")
      CC: stable@vger.kernel.org # 5.15+
      Reviewed-by: default avatarAnand Jain <anand.jain@oracle.com>
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ add Qu's note ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      95cd356c
    • Naohiro Aota's avatar
      btrfs: fix unnecessary increment of read error stat on write error · 98e8d36a
      Naohiro Aota authored
      Current btrfs_log_dev_io_error() increases the read error count even if the
      erroneous IO is a WRITE request. This is because it forget to use "else
      if", and all the error WRITE requests counts as READ error as there is (of
      course) no REQ_RAHEAD bit set.
      
      Fixes: c3a62baf ("btrfs: use chained bios when cloning")
      CC: stable@vger.kernel.org # 6.1+
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      Signed-off-by: default avatarNaohiro Aota <naohiro.aota@wdc.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      98e8d36a
    • void0red's avatar
      btrfs: handle btrfs_del_item errors in __btrfs_update_delayed_inode · c06016a0
      void0red authored
      Even if the slot is already read out, we may still need to re-balance
      the tree, thus it can cause error in that btrfs_del_item() call and we
      need to handle it properly.
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarvoid0red <void0red@gmail.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      c06016a0
    • Qu Wenruo's avatar
      btrfs: ioctl: return device fsid from DEV_INFO ioctl · 2943868a
      Qu Wenruo authored
      Currently user space utilizes dev info ioctl to grab the info of a
      certain devid, this includes its device uuid.  But the returned info is
      not enough to determine if a device is a seed.
      
      Commit a26d60de ("btrfs: sysfs: add devinfo/fsid to retrieve actual
      fsid from the device") exports the same value in sysfs so this is for
      parity with ioctl.  Add a new member, fsid, into
      btrfs_ioctl_dev_info_args, and populate the member with fsid value.
      
      This should not cause any compatibility problem, following the
      combinations:
      
      - Old user space, old kernel
      - Old user space, new kernel
        User space tool won't even check the new member.
      
      - New user space, old kernel
        The kernel won't touch the new member, and user space tool should
        zero out its argument, thus the new member is all zero.
      
        User space tool can then know the kernel doesn't support this fsid
        reporting, and falls back to whatever they can.
      
      - New user space, new kernel
        Go as planned.
      
        Would find the fsid member is no longer zero, and trust its value.
      Reviewed-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      2943868a
    • Boris Burkov's avatar
      btrfs: fix potential dead lock in size class loading logic · 12148367
      Boris Burkov authored
      As reported by Filipe, there's a potential deadlock caused by
      using btrfs_search_forward on commit_root. The locking there is
      unconditional, even if ->skip_locking and ->search_commit_root is set.
      It's not meant to be used for commit roots, so it always needs to do
      locking.
      
      So if another task is COWing a child node of the same root node and
      then needs to wait for block group caching to complete when trying to
      allocate a metadata extent, it deadlocks.
      
      For example:
      
      [539604.239315] sysrq: Show Blocked State
      [539604.240133] task:kworker/u16:6   state:D stack:0     pid:2119594 ppid:2      flags:0x00004000
      [539604.241613] Workqueue: btrfs-cache btrfs_work_helper [btrfs]
      [539604.242673] Call Trace:
      [539604.243129]  <TASK>
      [539604.243925]  __schedule+0x41d/0xee0
      [539604.244797]  ? rcu_read_lock_sched_held+0x12/0x70
      [539604.245399]  ? rwsem_down_read_slowpath+0x185/0x490
      [539604.246111]  schedule+0x5d/0xf0
      [539604.246593]  rwsem_down_read_slowpath+0x2da/0x490
      [539604.247290]  ? rcu_barrier_tasks_trace+0x10/0x20
      [539604.248090]  __down_read_common+0x3d/0x150
      [539604.248702]  down_read_nested+0xc3/0x140
      [539604.249280]  __btrfs_tree_read_lock+0x24/0x100 [btrfs]
      [539604.250097]  btrfs_read_lock_root_node+0x48/0x60 [btrfs]
      [539604.250915]  btrfs_search_forward+0x59/0x460 [btrfs]
      [539604.251781]  ? btrfs_global_root+0x50/0x70 [btrfs]
      [539604.252476]  caching_thread+0x1be/0x920 [btrfs]
      [539604.253167]  btrfs_work_helper+0xf6/0x400 [btrfs]
      [539604.253848]  process_one_work+0x24f/0x5a0
      [539604.254476]  worker_thread+0x52/0x3b0
      [539604.255166]  ? __pfx_worker_thread+0x10/0x10
      [539604.256047]  kthread+0xf0/0x120
      [539604.256591]  ? __pfx_kthread+0x10/0x10
      [539604.257212]  ret_from_fork+0x29/0x50
      [539604.257822]  </TASK>
      [539604.258233] task:btrfs-transacti state:D stack:0     pid:2236474 ppid:2      flags:0x00004000
      [539604.259802] Call Trace:
      [539604.260243]  <TASK>
      [539604.260615]  __schedule+0x41d/0xee0
      [539604.261205]  ? rcu_read_lock_sched_held+0x12/0x70
      [539604.262000]  ? rwsem_down_read_slowpath+0x185/0x490
      [539604.262822]  schedule+0x5d/0xf0
      [539604.263374]  rwsem_down_read_slowpath+0x2da/0x490
      [539604.266228]  ? lock_acquire+0x160/0x310
      [539604.266917]  ? rcu_read_lock_sched_held+0x12/0x70
      [539604.267996]  ? lock_contended+0x19e/0x500
      [539604.268720]  __down_read_common+0x3d/0x150
      [539604.269400]  down_read_nested+0xc3/0x140
      [539604.270057]  __btrfs_tree_read_lock+0x24/0x100 [btrfs]
      [539604.271129]  btrfs_read_lock_root_node+0x48/0x60 [btrfs]
      [539604.272372]  btrfs_search_slot+0x143/0xf70 [btrfs]
      [539604.273295]  update_block_group_item+0x9e/0x190 [btrfs]
      [539604.274282]  btrfs_start_dirty_block_groups+0x1c4/0x4f0 [btrfs]
      [539604.275381]  ? __mutex_unlock_slowpath+0x45/0x280
      [539604.276390]  btrfs_commit_transaction+0xee/0xed0 [btrfs]
      [539604.277391]  ? lock_acquire+0x1a4/0x310
      [539604.278080]  ? start_transaction+0xcb/0x6c0 [btrfs]
      [539604.279099]  transaction_kthread+0x142/0x1c0 [btrfs]
      [539604.279996]  ? __pfx_transaction_kthread+0x10/0x10 [btrfs]
      [539604.280673]  kthread+0xf0/0x120
      [539604.281050]  ? __pfx_kthread+0x10/0x10
      [539604.281496]  ret_from_fork+0x29/0x50
      [539604.281966]  </TASK>
      [539604.282255] task:fsstress        state:D stack:0     pid:2236483 ppid:1      flags:0x00004006
      [539604.283897] Call Trace:
      [539604.284700]  <TASK>
      [539604.285088]  __schedule+0x41d/0xee0
      [539604.285660]  schedule+0x5d/0xf0
      [539604.286175]  btrfs_wait_block_group_cache_progress+0xf2/0x170 [btrfs]
      [539604.287342]  ? __pfx_autoremove_wake_function+0x10/0x10
      [539604.288450]  find_free_extent+0xd93/0x1750 [btrfs]
      [539604.289256]  ? _raw_spin_unlock+0x29/0x50
      [539604.289911]  ? btrfs_get_alloc_profile+0x127/0x2a0 [btrfs]
      [539604.290843]  btrfs_reserve_extent+0x147/0x290 [btrfs]
      [539604.291943]  btrfs_alloc_tree_block+0xcb/0x3e0 [btrfs]
      [539604.292903]  __btrfs_cow_block+0x138/0x580 [btrfs]
      [539604.293773]  btrfs_cow_block+0x10e/0x240 [btrfs]
      [539604.294595]  btrfs_search_slot+0x7f3/0xf70 [btrfs]
      [539604.295585]  btrfs_update_device+0x71/0x1b0 [btrfs]
      [539604.296459]  btrfs_chunk_alloc_add_chunk_item+0xe0/0x340 [btrfs]
      [539604.297489]  btrfs_chunk_alloc+0x1bf/0x490 [btrfs]
      [539604.298335]  find_free_extent+0x6fa/0x1750 [btrfs]
      [539604.299174]  ? _raw_spin_unlock+0x29/0x50
      [539604.299950]  ? btrfs_get_alloc_profile+0x127/0x2a0 [btrfs]
      [539604.300918]  btrfs_reserve_extent+0x147/0x290 [btrfs]
      [539604.301797]  btrfs_alloc_tree_block+0xcb/0x3e0 [btrfs]
      [539604.303017]  ? lock_release+0x224/0x4a0
      [539604.303855]  __btrfs_cow_block+0x138/0x580 [btrfs]
      [539604.304789]  btrfs_cow_block+0x10e/0x240 [btrfs]
      [539604.305611]  btrfs_search_slot+0x7f3/0xf70 [btrfs]
      [539604.306682]  ? btrfs_global_root+0x50/0x70 [btrfs]
      [539604.308198]  lookup_inline_extent_backref+0x17b/0x7a0 [btrfs]
      [539604.309254]  lookup_extent_backref+0x43/0xd0 [btrfs]
      [539604.310122]  __btrfs_free_extent+0xf8/0x810 [btrfs]
      [539604.310874]  ? lock_release+0x224/0x4a0
      [539604.311724]  ? btrfs_merge_delayed_refs+0x17b/0x1d0 [btrfs]
      [539604.313023]  __btrfs_run_delayed_refs+0x2ba/0x1260 [btrfs]
      [539604.314271]  btrfs_run_delayed_refs+0x8f/0x1c0 [btrfs]
      [539604.315445]  ? rcu_read_lock_sched_held+0x12/0x70
      [539604.316706]  btrfs_commit_transaction+0xa2/0xed0 [btrfs]
      [539604.317855]  ? do_raw_spin_unlock+0x4b/0xa0
      [539604.318544]  ? _raw_spin_unlock+0x29/0x50
      [539604.319240]  create_subvol+0x53d/0x6e0 [btrfs]
      [539604.320283]  btrfs_mksubvol+0x4f5/0x590 [btrfs]
      [539604.321220]  __btrfs_ioctl_snap_create+0x11b/0x180 [btrfs]
      [539604.322307]  btrfs_ioctl_snap_create_v2+0xc6/0x150 [btrfs]
      [539604.323295]  btrfs_ioctl+0x9f7/0x33e0 [btrfs]
      [539604.324331]  ? rcu_read_lock_sched_held+0x12/0x70
      [539604.325137]  ? lock_release+0x224/0x4a0
      [539604.325808]  ? __x64_sys_ioctl+0x87/0xc0
      [539604.326467]  __x64_sys_ioctl+0x87/0xc0
      [539604.327109]  do_syscall_64+0x38/0x90
      [539604.327875]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
      [539604.328792] RIP: 0033:0x7f05a7babaeb
      
      This needs to use regular btrfs_search_slot() with some skip and stop
      logic.
      
      Since we only consider five samples (five search slots), don't bother
      with the complexity of looking for commit_root_sem contention. If
      necessary, it can be added to the load function in between samples.
      Reported-by: default avatarFilipe Manana <fdmanana@kernel.org>
      Link: https://lore.kernel.org/linux-btrfs/CAL3q7H7eKMD44Z1+=Kb-1RFMMeZpAm2fwyO59yeBwCcSOU80Pg@mail.gmail.com/
      Fixes: c7eec3d9 ("btrfs: load block group size class when caching")
      Signed-off-by: default avatarBoris Burkov <boris@bur.io>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      12148367
  2. 01 Mar, 2023 1 commit
  3. 15 Feb, 2023 33 commits