Changes in ref-verify.c

7c4e39f9 - btrfs: ref-verify: fix use-after-free after invalid ref action

Fri, 15 Nov 2024 11:29:21 +0000

btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 ================================================================== BUG: KASAN: slab-use-after-free in rb_first+0x69/0x70 lib/rbtree.c:473 Read of size 8 at addr ffff888042d1af38 by task syz.0.0/5329 CPU: 0 UID: 0 PID: 5329 Comm: syz.0.0 Not tainted 6.12.0-rc7-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rb_first+0x69/0x70 lib/rbtree.c:473 free_block_entry+0x78/0x230 fs/btrfs/ref-verify.c:248 btrfs_free_ref_cache+0xa3/0x100 fs/btrfs/ref-verify.c:917 btrfs_ref_tree_mod+0x139f/0x15e0 fs/btrfs/ref-verify.c:898 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f996df7e719 RSP: 002b:00007f996ede7038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f996e135f80 RCX: 00007f996df7e719 RDX: 0000000020000180 RSI: 00000000c4009420 RDI: 0000000000000004 RBP: 00007f996dff139e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f996e135f80 R15: 00007fff79f32e68 Allocated by task 5329: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:257 [inline] __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4295 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] btrfs_ref_tree_mod+0x264/0x15e0 fs/btrfs/ref-verify.c:701 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5329: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_hook mm/slub.c:2342 [inline] slab_free mm/slub.c:4579 [inline] kfree+0x1a0/0x440 mm/slub.c:4727 btrfs_ref_tree_mod+0x136c/0x15e0 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888042d1af00 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 56 bytes inside of freed 64-byte region [ffff888042d1af00, ffff888042d1af40) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x42d1a anon flags: 0x4fff00000000000(node=1|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 04fff00000000000 ffff88801ac418c0 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000200020 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 5055, tgid 5055 (dhcpcd-run-hook), ts 40377240074, free_ts 40376848335 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1541 prep_new_page mm/page_alloc.c:1549 [inline] get_page_from_freelist+0x3649/0x3790 mm/page_alloc.c:3459 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4735 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 alloc_slab_page+0x6a/0x140 mm/slub.c:2412 allocate_slab+0x5a/0x2f0 mm/slub.c:2578 new_slab mm/slub.c:2631 [inline] ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3818 __slab_alloc+0x58/0xa0 mm/slub.c:3908 __slab_alloc_node mm/slub.c:3961 [inline] slab_alloc_node mm/slub.c:4122 [inline] __do_kmalloc_node mm/slub.c:4263 [inline] __kmalloc_noprof+0x25a/0x400 mm/slub.c:4276 kmalloc_noprof include/linux/slab.h:882 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] tomoyo_encode2 security/tomoyo/realpath.c:45 [inline] tomoyo_encode+0x26f/0x540 security/tomoyo/realpath.c:80 tomoyo_realpath_from_path+0x59e/0x5e0 security/tomoyo/realpath.c:283 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_check_open_permission+0x255/0x500 security/tomoyo/file.c:771 security_file_open+0x777/0x990 security/security.c:3109 do_dentry_open+0x369/0x1460 fs/open.c:945 vfs_open+0x3e/0x330 fs/open.c:1088 do_open fs/namei.c:3774 [inline] path_openat+0x2c84/0x3590 fs/namei.c:3933 page last free pid 5055 tgid 5055 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1112 [inline] free_unref_page+0xcfb/0xf20 mm/page_alloc.c:2642 free_pipe_info+0x300/0x390 fs/pipe.c:860 put_pipe_info fs/pipe.c:719 [inline] pipe_release+0x245/0x320 fs/pipe.c:742 __fput+0x23f/0x880 fs/file_table.c:431 __do_sys_close fs/open.c:1567 [inline] __se_sys_close fs/open.c:1552 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1552 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff888042d1ae00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff888042d1ae80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc >ffff888042d1af00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ffff888042d1af80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ffff888042d1b000: 00 00 00 00 00 fc fc 00 00 00 00 00 fc fc 00 00Reported-by: syzbot+7325f164162e200000c1@syzkaller.appspotmail.comLink: https://lore.kernel.org/linux-btrfs/673723eb.050a0220.1324f8.00a8.GAE@google.com/T/#uFixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")CC: stable@vger.kernel.org # 4.19+Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

9da45c88 - btrfs: fix uninitialized return value in the ref-verify tool

Sun, 23 Jun 2024 11:50:26 +0000

btrfs: fix uninitialized return value in the ref-verify toolIn the ref-verify tool, when processing the inline references of an extentitem, we may end up returning with uninitialized return value, because:1) The 'ret' variable is not initialized if there are no inline extent references ('ptr' == 'end' before the while loop starts);2) If we find an extent owner inline reference we don't initialize 'ret'.So fix these cases by initializing 'ret' to 0 when declaring the variableand set it to -EINVAL if we find an extent owner inline references andsimple quotas are not enabled (as well as print an error message).Reported-by: Mirsad Todorovac Link: https://lore.kernel.org/linux-btrfs/59b40ebe-c824-457d-8b24-0bbca69d472b@gmail.com/Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

53667634 - btrfs: rename btrfs_data_ref->ino to ->objectid

Sat, 13 Apr 2024 03:01:38 +0000

btrfs: rename btrfs_data_ref->ino to ->objectidThis is how we refer to it in the rest of the extent reference relatedcode, make it consistent.Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

12390e42 - btrfs: rename ->len to ->num_bytes in btrfs_ref

Sat, 13 Apr 2024 00:52:26 +0000

btrfs: rename ->len to ->num_bytes in btrfs_refWe consistently use ->num_bytes everywhere through the delayed ref code,except in btrfs_ref. Rename btrfs_ref to match all the other code.Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

f2e69a77 - btrfs: move ref_root into btrfs_ref

Fri, 12 Apr 2024 23:37:53 +0000

btrfs: move ref_root into btrfs_refWe have this in both btrfs_tree_ref and btrfs_data_ref, which is justwasting space and making the code more complicated. Move this intobtrfs_ref proper and update all the call sites to do the assignment inbtrfs_ref.Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

f03e274a - btrfs: ref-verify: free ref cache before clearing mount opt

Wed, 03 Jan 2024 10:31:27 +0000

btrfs: ref-verify: free ref cache before clearing mount optAs clearing REF_VERIFY mount option indicates there were some errors in aref-verify process, a ref cache is not relevant anymore and should befreed.btrfs_free_ref_cache() requires REF_VERIFY option being set so callit just before clearing the mount option.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.Reported-by: syzbot+be14ed7728594dc8bd42@syzkaller.appspotmail.comFixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")CC: stable@vger.kernel.org # 5.4+Closes: https://lore.kernel.org/lkml/000000000000e5a65c05ee832054@google.com/Reported-by: syzbot+c563a3c79927971f950f@syzkaller.appspotmail.comCloses: https://lore.kernel.org/lkml/0000000000007fe09705fdc6086c@google.com/Reviewed-by: Anand Jain Signed-off-by: Fedor Pchelkin Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

f91192cd - btrfs: ref-verify: fix memory leaks in btrfs_ref_tree_mod()

Sat, 18 Nov 2023 09:10:12 +0000

btrfs: ref-verify: fix memory leaks in btrfs_ref_tree_mod()In btrfs_ref_tree_mod(), when !parent 're' was allocated throughkmalloc(). In the following code, if an error occurs, the execution willbe redirected to 'out' or 'out_unlock' and the function will be exited.However, on some of the paths, 're' are not deallocated and may lead tomemory leaks.For example: lookup_block_entry() for 'be' returns NULL, the out labelwill be invoked. During that flow ref and 'ra' are freed but not 're',which can potentially lead to a memory leak.CC: stable@vger.kernel.org # 5.10+Reported-and-tested-by: syzbot+d66de4cbf532749df35f@syzkaller.appspotmail.comCloses: https://syzkaller.appspot.com/bug?extid=d66de4cbf532749df35fSigned-off-by: Bragatheswaran Manickavel Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

d9a620f7 - btrfs: new inline ref storing owning subvol of data extents

Mon, 30 Jan 2023 22:45:55 +0000

btrfs: new inline ref storing owning subvol of data extentsIn order to implement simple quota groups, we need to be able toassociate a data extent with the subvolume that created it. Once youaccount for reflink, this information cannot be recovered withoutexplicitly storing it. Options for storing it are:- a new key/item- a new extent inline ref itemThe former is backwards compatible, but wastes space, the latter isincompat, but is efficient in space and reuses the existing inline refmachinery, while only abusing it a tiny amount -- specifically, the newitem is not a ref, per-se.Signed-off-by: Boris Burkov Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

610647d7 - btrfs: rename tree_ref and data_ref owning_root

Wed, 28 Jun 2023 21:32:58 +0000

btrfs: rename tree_ref and data_ref owning_rootcommit 113479d5b8eb ("btrfs: rename root fields in delayed refs structs")changed these from ref_root to owning_root. However, there are manycircumstances where that name is not really accurate and the root on theref struct _is_ the referring root. In general, these are not the owningroot, though it does happen in some ref merging cases involvingoverwrites during snapshots and similar.Simple quotas cares quite a bit about tracking the original owner of anextent through delayed refs, so rename these back to free up the namefor the real owning root (which will live on the generic btrfs_ref andthe head ref)Reviewed-by: Josef Bacik Signed-off-by: Boris Burkov Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

9580503b - btrfs: reformat remaining kdoc style comments

Thu, 07 Sep 2023 23:09:25 +0000

btrfs: reformat remaining kdoc style commentsFunction name in the comment does not bring much value to code notexposed as API and we don't stick to the kdoc format anymore. Updateformatting of parameter descriptions.Reviewed-by: Qu Wenruo Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

07e81dc9 - btrfs: move accessor helpers into accessors.h

Wed, 19 Oct 2022 14:51:00 +0000

btrfs: move accessor helpers into accessors.hThis is a large patch, but because they're all macros it's impossible tosplit up. Simply copy all of the item accessors in ctree.h and pastethem in accessors.h, and then update any files to include the header soeverything compiles.Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ reformat comments, style fixups ]Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

fc97a410 - btrfs: move mount option definitions to fs.h

Wed, 19 Oct 2022 14:50:53 +0000

btrfs: move mount option definitions to fs.hThese are fs wide definitions and helpers, move them out of ctree.h andinto fs.h.Reviewed-by: Johannes Thumshirn Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

9b569ea0 - btrfs: move the printk helpers out of ctree.h

Wed, 19 Oct 2022 14:50:49 +0000

btrfs: move the printk helpers out of ctree.hWe have a bunch of printk helpers that are in ctree.h. These havenothing to do with ctree.c, so move them into their own header.Subsequent patches will cleanup the printk helpers.Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

29cbcf40 - btrfs: stop accessing ->extent_root directly

Fri, 05 Nov 2021 20:45:45 +0000

btrfs: stop accessing ->extent_root directlyWhen we start having multiple extent roots we'll need to use a helper toget to the correct extent_root. Rename fs_info->extent_root to_extent_root and convert all of the users of the extent root to usingthe btrfs_extent_root() helper. This will allow us to easily clean upthe remaining direct accesses in the future.Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

3212fa14 - btrfs: drop the _nr from the item helpers

Thu, 21 Oct 2021 18:58:35 +0000

btrfs: drop the _nr from the item helpersNow that all call sites are using the slot number to modify item values,rename the SETGET helpers to raw_item_*(), and then rework the _nr()helpers to be the btrfs_item_*() btrfs_set_item_*() helpers, and thenrename all of the callers to the new helpers.Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

113479d5 - btrfs: rename root fields in delayed refs structs

Tue, 12 Oct 2021 08:21:33 +0000

btrfs: rename root fields in delayed refs structsBoth data and metadata delayed ref structures have fields namedroot/ref_root respectively. Those are somewhat cryptic and don't reallyconvey the real meaning. In fact those roots are really the originalowners of the respective block (i.e in case of a snapshot a data delayedref will contain the original root that owns the given block). Renamethose fields accordingly and adjust comments.Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

5a656c36 - btrfs: stop doing GFP_KERNEL memory allocations in the ref verify tool

Tue, 20 Jul 2021 15:05:23 +0000

btrfs: stop doing GFP_KERNEL memory allocations in the ref verify toolIn commit 351cbf6e4410e7 ("btrfs: use nofs allocations for running delayeditems") we wrapped all btree updates when running delayed items withmemalloc_nofs_save() and memalloc_nofs_restore(), due to a lock inversiondetected by lockdep involving reclaim and the mutex of delayed nodes.The problem is because the ref verify tool does some memory allocationswith GFP_KERNEL, which can trigger reclaim and reclaim can trigger inodeeviction, which requires locking the mutex of an inode's delayed node.On the other hand the ref verify tool is called when allocating metadataextents as part of operations that modify a btree, which is a problem whenrunning delayed nodes, where we do btree updates while holding the mutexof a delayed node. This is what caused the lockdep warning.Instead of wrapping every btree update when running delayed nodes, changethe ref verify tool to never do GFP_KERNEL allocations, because:1) We get less repeated code, which at the moment does not even have a comment mentioning why we need to setup the NOFS context, which is a recommended good practice as mentioned at Documentation/core-api/gfp_mask-from-fs-io.rst2) The ref verify tool is something meant only for debugging and not something that should be enabled on non-debug / non-development kernels;3) We may have yet more places outside delayed-inode.c where we have similar problem: doing btree updates while holding some lock and then having the GFP_KERNEL memory allocations, from the ref verify tool, trigger reclaim and trying again to acquire the same lock through the reclaim path. Or we could get more such cases in the future, therefore this change prevents getting into similar cases when using the ref verify tool.Curiously most of the memory allocations done by the ref verify toolwere already using GFP_NOFS, except a few ones for no apparent reason.Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

aedb9d90 - btrfs: ref-verify: use 'inline void' keyword ordering

Fri, 19 Feb 2021 06:54:17 +0000

btrfs: ref-verify: use 'inline void' keyword orderingFix build warnings of function signature when CONFIG_STACKTRACE is notenabled by reordering the 'inline' and 'void' keywords.../fs/btrfs/ref-verify.c:221:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration] static void inline __save_stack_trace(struct ref_action *ra)../fs/btrfs/ref-verify.c:225:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration] static void inline __print_stack_trace(struct btrfs_fs_info *fs_info,Signed-off-by: Randy Dunlap Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

1478143a - btrfs: ref-verify: make sure owner is set for all refs

Wed, 16 Dec 2020 16:18:47 +0000

btrfs: ref-verify: make sure owner is set for all refsI noticed that shared ref entries in ref-verify didn't have the properowner set, which caused me to think there was something seriously wrong.However the problem is if we have a parent we simply weren't filling outthe owner part of the reference, even though we have it.Fix this by making sure we set all the proper fields when we modify areference, this way we'll have the proper owner if a problem happens andwe don't waste time thinking we're updating the wrong level.Signed-off-by: Josef Bacik Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c

0d73a11c - btrfs: ref-verify: pass down tree block level when building refs

Wed, 16 Dec 2020 16:18:46 +0000

btrfs: ref-verify: pass down tree block level when building refsI noticed that sometimes I would have the wrong level printed out withref-verify while testing some error injection related problems. This isbecause we only get the level from the main extent item, but ourreferences could go off the current leaf into another, and at that pointwe lose our level.Fix this by keeping track of the last tree block level that we found,the same way we keep track of our bytenr and num_bytes, in case wehappen to wander into another leaf while still processing the referencesfor a bytenr.Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/ref-verify.c