1. 15 May, 2024 5 commits
    • Filipe Manana's avatar
      btrfs: fix end of tree detection when searching for data extent ref · dddff821
      Filipe Manana authored
      At lookup_extent_data_ref() we are incorrectly checking if we are at the
      last slot of the last leaf in the extent tree. We are returning -ENOENT
      if btrfs_next_leaf() returns a value greater than 1, but btrfs_next_leaf()
      never returns anything greater than 1:
      
      1) It returns < 0 on error;
      
      2) 0 if there is a next leaf (or a new item was added to the end of the
         current leaf after releasing the path);
      
      3) 1 if there are no more leaves (and no new items were added to the last
         leaf after releasing the path).
      
      So fix this by checking if the return value is greater than zero instead
      of being greater than one.
      
      Fixes: 1618aa3c ("btrfs: simplify return variables in lookup_extent_data_ref()")
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      dddff821
    • Lu Yao's avatar
      btrfs: scrub: initialize ret in scrub_simple_mirror() to fix compilation warning · b4e585ff
      Lu Yao authored
      The following error message is displayed:
        ../fs/btrfs/scrub.c:2152:9: error: ‘ret’ may be used uninitialized
        in this function [-Werror=maybe-uninitialized]"
      
      Compiler version: gcc version: (Debian 10.2.1-6) 10.2.1 20210110
      Reviewed-by: default avatarBoris Burkov <boris@bur.io>
      Signed-off-by: default avatarLu Yao <yaolu@kylinos.cn>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      b4e585ff
    • Filipe Manana's avatar
      btrfs: zoned: fix use-after-free due to race with dev replace · 0090d6e1
      Filipe Manana authored
      While loading a zone's info during creation of a block group, we can race
      with a device replace operation and then trigger a use-after-free on the
      device that was just replaced (source device of the replace operation).
      
      This happens because at btrfs_load_zone_info() we extract a device from
      the chunk map into a local variable and then use the device while not
      under the protection of the device replace rwsem. So if there's a device
      replace operation happening when we extract the device and that device
      is the source of the replace operation, we will trigger a use-after-free
      if before we finish using the device the replace operation finishes and
      frees the device.
      
      Fix this by enlarging the critical section under the protection of the
      device replace rwsem so that all uses of the device are done inside the
      critical section.
      
      CC: stable@vger.kernel.org # 6.1.x: 15c12fcc: btrfs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info
      CC: stable@vger.kernel.org # 6.1.x: 09a46725: btrfs: zoned: factor out per-zone logic from btrfs_load_block_group_zone_info
      CC: stable@vger.kernel.org # 6.1.x: 9e0e3e74: btrfs: zoned: factor out single bg handling from btrfs_load_block_group_zone_info
      CC: stable@vger.kernel.org # 6.1.x: 87463f7e: btrfs: zoned: factor out DUP bg handling from btrfs_load_block_group_zone_info
      CC: stable@vger.kernel.org # 6.1.x
      Reviewed-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      0090d6e1
    • Boris Burkov's avatar
      btrfs: qgroup: fix qgroup id collision across mounts · 2b8aa78c
      Boris Burkov authored
      If we delete subvolumes whose ID is the largest in the filesystem, then
      unmount and mount again, then btrfs_init_root_free_objectid on the
      tree_root will select a subvolid smaller than that one and thus allow
      reusing it.
      
      If we are also using qgroups (and particularly squotas) it is possible
      to delete the subvol without deleting the qgroup. In that case, we will
      be able to create a new subvol whose id already has a level 0 qgroup.
      This will result in re-using that qgroup which would then lead to
      incorrect accounting.
      
      Fixes: 6ed05643 ("btrfs: create qgroup earlier in snapshot creation")
      CC: stable@vger.kernel.org # 6.7+
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarBoris Burkov <boris@bur.io>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      2b8aa78c
    • David Sterba's avatar
      btrfs: qgroup: update rescan message levels and error codes · 1fa7603d
      David Sterba authored
      On filesystems without enabled quotas there's still a warning message in
      the logs when rescan is called. In that case it's not a problem that
      should be reported, rescan can be called unconditionally.  Change the
      error code to ENOTCONN which is used for 'quotas not enabled' elsewhere.
      
      Remove message (also a warning) when rescan is called during an ongoing
      rescan, this brings no useful information and the error code is
      sufficient.
      
      Change message levels to debug for now, they can be removed eventually.
      
      CC: stable@vger.kernel.org # 6.6+
      Reviewed-by: default avatarBoris Burkov <boris@bur.io>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      1fa7603d
  2. 07 May, 2024 35 commits