1. 19 10月, 2021 6 次提交
  2. 18 10月, 2021 9 次提交
  3. 14 10月, 2021 1 次提交
  4. 12 10月, 2021 8 次提交
  5. 08 10月, 2021 8 次提交
    • J
      btrfs: fix abort logic in btrfs_replace_file_extents · 4afb912f
      Josef Bacik 提交于
      Error injection testing uncovered a case where we'd end up with a
      corrupt file system with a missing extent in the middle of a file.  This
      occurs because the if statement to decide if we should abort is wrong.
      
      The only way we would abort in this case is if we got a ret !=
      -EOPNOTSUPP and we called from the file clone code.  However the
      prealloc code uses this path too.  Instead we need to abort if there is
      an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only
      if we came from the clone file code.
      
      CC: stable@vger.kernel.org # 5.10+
      Reviewed-by: NNikolay Borisov <nborisov@suse.com>
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NJosef Bacik <josef@toxicpanda.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      4afb912f
    • F
      btrfs: check for error when looking up inode during dir entry replay · cfd31269
      Filipe Manana 提交于
      At replay_one_name(), we are treating any error from btrfs_lookup_inode()
      as if the inode does not exists. Fix this by checking for an error and
      returning it to the caller.
      
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      cfd31269
    • F
      btrfs: unify lookup return value when dir entry is missing · 8dcbc261
      Filipe Manana 提交于
      btrfs_lookup_dir_index_item() and btrfs_lookup_dir_item() lookup for dir
      entries and both are used during log replay or when updating a log tree
      during an unlink.
      
      However when the dir item does not exists, btrfs_lookup_dir_item() returns
      NULL while btrfs_lookup_dir_index_item() returns PTR_ERR(-ENOENT), and if
      the dir item exists but there is no matching entry for a given name or
      index, both return NULL. This makes the call sites during log replay to
      be more verbose than necessary and it makes it easy to miss this slight
      difference. Since we don't need to distinguish between those two cases,
      make btrfs_lookup_dir_index_item() always return NULL when there is no
      matching directory entry - either because there isn't any dir entry or
      because there is one but it does not match the given name and index.
      
      Also rename the argument 'objectid' of btrfs_lookup_dir_index_item() to
      'index' since it is supposed to match an index number, and the name
      'objectid' is not very good because it can easily be confused with an
      inode number (like the inode number a dir entry points to).
      
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      8dcbc261
    • F
      btrfs: deal with errors when adding inode reference during log replay · 52db7779
      Filipe Manana 提交于
      At __inode_add_ref(), we treating any error returned from
      btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning
      that there is no existing directory entry in the fs/subvolume tree.
      This is not correct since we can get errors such as, for example, -EIO
      when reading extent buffers while searching the fs/subvolume's btree.
      
      So fix that and return the error to the caller when it is not -ENOENT.
      
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      52db7779
    • F
      btrfs: deal with errors when replaying dir entry during log replay · e15ac641
      Filipe Manana 提交于
      At replay_one_one(), we are treating any error returned from
      btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning
      that there is no existing directory entry in the fs/subvolume tree.
      This is not correct since we can get errors such as, for example, -EIO
      when reading extent buffers while searching the fs/subvolume's btree.
      
      So fix that and return the error to the caller when it is not -ENOENT.
      
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      e15ac641
    • F
      btrfs: deal with errors when checking if a dir entry exists during log replay · 77a5b9e3
      Filipe Manana 提交于
      Currently inode_in_dir() ignores errors returned from
      btrfs_lookup_dir_index_item() and from btrfs_lookup_dir_item(), treating
      any errors as if the directory entry does not exists in the fs/subvolume
      tree, which is obviously not correct, as we can get errors such as -EIO
      when reading extent buffers while searching the fs/subvolume's tree.
      
      Fix that by making inode_in_dir() return the errors and making its only
      caller, add_inode_ref(), deal with returned errors as well.
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      77a5b9e3
    • J
      btrfs: update refs for any root except tree log roots · d175209b
      Josef Bacik 提交于
      I hit a stuck relocation on btrfs/061 during my overnight testing.  This
      turned out to be because we had left over extent entries in our extent
      root for a data reloc inode that no longer existed.  This happened
      because in btrfs_drop_extents() we only update refs if we have SHAREABLE
      set or we are the tree_root.  This regression was introduced by
      aeb935a4 ("btrfs: don't set SHAREABLE flag for data reloc tree")
      where we stopped setting SHAREABLE for the data reloc tree.
      
      The problem here is we actually do want to update extent references for
      data extents in the data reloc tree, in fact we only don't want to
      update extent references if the file extents are in the log tree.
      Update this check to only skip updating references in the case of the
      log tree.
      
      This is relatively rare, because you have to be running scrub at the
      same time, which is what btrfs/061 does.  The data reloc inode has its
      extents pre-allocated, and then we copy the extent into the
      pre-allocated chunks.  We theoretically should never be calling
      btrfs_drop_extents() on a data reloc inode.  The exception of course is
      with scrub, if our pre-allocated extent falls inside of the block group
      we are scrubbing, then the block group will be marked read only and we
      will be forced to cow that extent.  This means we will call
      btrfs_drop_extents() on that range when we COW that file extent.
      
      This isn't really problematic if we do this, the data reloc inode
      requires that our extent lengths match exactly with the extent we are
      copying, thankfully we validate the extent is correct with
      get_new_location(), so if we happen to COW only part of the extent we
      won't link it in when we do the relocation, so we are safe from any
      other shenanigans that arise because of this interaction with scrub.
      
      Fixes: aeb935a4 ("btrfs: don't set SHAREABLE flag for data reloc tree")
      CC: stable@vger.kernel.org # 5.8+
      Reviewed-by: NQu Wenruo <wqu@suse.com>
      Signed-off-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      d175209b
    • Q
      btrfs: unlock newly allocated extent buffer after error · 19ea40dd
      Qu Wenruo 提交于
      [BUG]
      There is a bug report that injected ENOMEM error could leave a tree
      block locked while we return to user-space:
      
        BTRFS info (device loop0): enabling ssd optimizations
        FAULT_INJECTION: forcing a failure.
        name failslab, interval 1, probability 0, space 0, times 0
        CPU: 0 PID: 7579 Comm: syz-executor Not tainted 5.15.0-rc1 #16
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
        rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
        Call Trace:
         __dump_stack lib/dump_stack.c:88 [inline]
         dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106
         fail_dump lib/fault-inject.c:52 [inline]
         should_fail+0x13c/0x160 lib/fault-inject.c:146
         should_failslab+0x5/0x10 mm/slab_common.c:1328
         slab_pre_alloc_hook.constprop.99+0x4e/0xc0 mm/slab.h:494
         slab_alloc_node mm/slub.c:3120 [inline]
         slab_alloc mm/slub.c:3214 [inline]
         kmem_cache_alloc+0x44/0x280 mm/slub.c:3219
         btrfs_alloc_delayed_extent_op fs/btrfs/delayed-ref.h:299 [inline]
         btrfs_alloc_tree_block+0x38c/0x670 fs/btrfs/extent-tree.c:4833
         __btrfs_cow_block+0x16f/0x7d0 fs/btrfs/ctree.c:415
         btrfs_cow_block+0x12a/0x300 fs/btrfs/ctree.c:570
         btrfs_search_slot+0x6b0/0xee0 fs/btrfs/ctree.c:1768
         btrfs_insert_empty_items+0x80/0xf0 fs/btrfs/ctree.c:3905
         btrfs_new_inode+0x311/0xa60 fs/btrfs/inode.c:6530
         btrfs_create+0x12b/0x270 fs/btrfs/inode.c:6783
         lookup_open+0x660/0x780 fs/namei.c:3282
         open_last_lookups fs/namei.c:3352 [inline]
         path_openat+0x465/0xe20 fs/namei.c:3557
         do_filp_open+0xe3/0x170 fs/namei.c:3588
         do_sys_openat2+0x357/0x4a0 fs/open.c:1200
         do_sys_open+0x87/0xd0 fs/open.c:1216
         do_syscall_x64 arch/x86/entry/common.c:50 [inline]
         do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80
         entry_SYSCALL_64_after_hwframe+0x44/0xae
        RIP: 0033:0x46ae99
        Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
        89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
        01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007f46711b9c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
        RAX: ffffffffffffffda RBX: 000000000078c0a0 RCX: 000000000046ae99
        RDX: 0000000000000000 RSI: 00000000000000a1 RDI: 0000000020005800
        RBP: 00007f46711b9c80 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000017
        R13: 0000000000000000 R14: 000000000078c0a0 R15: 00007ffc129da6e0
      
        ================================================
        WARNING: lock held when returning to user space!
        5.15.0-rc1 #16 Not tainted
        ------------------------------------------------
        syz-executor/7579 is leaving the kernel with locks still held!
        1 lock held by syz-executor/7579:
         #0: ffff888104b73da8 (btrfs-tree-01/1){+.+.}-{3:3}, at:
        __btrfs_tree_lock+0x2e/0x1a0 fs/btrfs/locking.c:112
      
      [CAUSE]
      In btrfs_alloc_tree_block(), after btrfs_init_new_buffer(), the new
      extent buffer @buf is locked, but if later operations like adding
      delayed tree ref fail, we just free @buf without unlocking it,
      resulting above warning.
      
      [FIX]
      Unlock @buf in out_free_buf: label.
      Reported-by: NHao Sun <sunhao.th@gmail.com>
      Link: https://lore.kernel.org/linux-btrfs/CACkBjsZ9O6Zr0KK1yGn=1rQi6Crh1yeCRdTSBxx9R99L4xdn-Q@mail.gmail.com/
      CC: stable@vger.kernel.org # 5.4+
      Signed-off-by: NQu Wenruo <wqu@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      19ea40dd
  6. 07 10月, 2021 6 次提交
  7. 06 10月, 2021 1 次提交
  8. 05 10月, 2021 1 次提交