Changes in locking.c

6149c82b - btrfs: update include and forward declarations in headers

Wed, 12 Feb 2025 20:22:16 +0000

btrfs: update include and forward declarations in headersPass over all header files and add missing forward declarations,includes or fix include types.Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

b628c139 - btrfs: remove unused btrfs_try_tree_write_lock()

Thu, 03 Oct 2024 14:27:27 +0000

btrfs: remove unused btrfs_try_tree_write_lock()btrfs_try_tree_write_lock() has been unused since commit50b21d7a066f ("btrfs: submit a writeback bio per extent_buffer").Remove it as we don't need it anymore.Reviewed-by: Christoph Hellwig Reviewed-by: Qu Wenruo Signed-off-by: Dr. David Alan Gilbert Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

e094f480 - btrfs: change root->root_key.objectid to btrfs_root_id()

Mon, 15 Apr 2024 20:16:23 +0000

btrfs: change root->root_key.objectid to btrfs_root_id()A comment from Filipe on one of my previous cleanups brought myattention to a new helper we have for getting the root id of a root,which makes it easier to read in the code.The changes where made with the following Coccinelle semantic patch:// @@expression E,E1;@@( E->root_key.objectid = E1|- E->root_key.objectid+ btrfs_root_id(E))// Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ minor style fixups ]Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

c79f57ea - btrfs: avoid pointless wake ups of drew lock readers

Mon, 18 Mar 2024 11:08:30 +0000

btrfs: avoid pointless wake ups of drew lock readersWhen unlocking a write lock on a drew lock, at btrfs_drew_write_unlock(),it's pointless to wake up tasks waiting to acquire a read lock if wedidn't decrement the 'writers' counter down to 0, since a read lock canonly be acquired when the counter reaches a value of 0. Doing so isharmless from a functional point of view, but it's not efficient due tounnecessarily waking up tasks just for them to sleep again on thewaitqueue.So change this to wake up readers only if we decremented the 'writers'counter to 0.Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

2066bbfc - btrfs: locking: rename __btrfs_tree_lock() and __btrfs_tree_read_lock()

Fri, 15 Mar 2024 12:41:45 +0000

btrfs: locking: rename __btrfs_tree_lock() and __btrfs_tree_read_lock()The __btrfs_tree_lock() and __btrfs_tree_read_lock() are using a namingwith a double underscore prefix, which is specially not proper forexported functions. Remove the double underscore prefix from their nameand add the "_nested" suffix.Reviewed-by: Anand Jain Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

f40ca9cb - btrfs: locking: inline btrfs_tree_lock() and btrfs_tree_read_lock()

Fri, 15 Mar 2024 12:15:53 +0000

btrfs: locking: inline btrfs_tree_lock() and btrfs_tree_read_lock()The functions btrfs_tree_lock() and btrfs_tree_read_lock() are verytrivial so that can be made inline and avoid call overhead, as theyare very often called inside critical sections (when searching a btreefor example, attempting to lock a child node/leaf while holding a lockon the parent).So make them static inline, which even reduces the size of the btrfsmodule a little bit.Before this change: $ size fs/btrfs/btrfs.ko text data bss dec hex filename 1718786 156276 16920 1891982 1cde8e fs/btrfs/btrfs.koAfter this change: $ size fs/btrfs/btrfs.ko text data bss dec hex filename 1718650 156260 16920 1891830 1cddf6 fs/btrfs/btrfs.koRunning fs_mark also showed a tiny improvement with this script: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 FILES=100000 THREADS=$(nproc --all) echo "performance" | \ tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor umount $DEV &> /dev/null mkfs.btrfs -f $DEV mount $DEV $MNT OPTS="-S 0 -L 5 -n $FILES -s 0 -t $THREADS -k" for ((i = 1; i <= $THREADS; i++)); do OPTS="$OPTS -d $MNT/d$i" done fs_mark $OPTS umount $MNTBefore this change: FSUse% Count Size Files/sec App Overhead 10 1200000 0 180894.0 10705410 16 2400000 0 228211.4 10765738 23 3600000 0 215969.6 11011072 30 4800000 0 199077.1 11145587 46 6000000 0 176624.1 11658470After this change: FSUse% Count Size Files/sec App Overhead 10 1200000 0 185312.3 10708377 16 2400000 0 229320.4 10858013 23 3600000 0 217958.7 11006167 30 4800000 0 205122.9 11112899 46 6000000 0 178039.1 11438852Reviewed-by: Anand Jain Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

504a00ac - btrfs: change BUG_ON to assertion when verifying lockdep class setup

Tue, 23 Jan 2024 22:09:18 +0000

btrfs: change BUG_ON to assertion when verifying lockdep class setupThe BUG_ON in btrfs_set_buffer_lockdep_class() is a sanity check of thelevel which is verified in callers, e.g. when initializing an extentbuffer or reading from an eb header. Change it to an assertion as thiswould not happen unless things are really bad and would fail elsewheretoo.Reviewed-by: Josef Bacik Reviewed-by: Anand Jain Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

2b712e3b - btrfs: remove unused included headers

Thu, 25 Jan 2024 16:44:47 +0000

btrfs: remove unused included headersWith help of neovim, LSP and clangd we can identify header files thatare not actually needed to be included in the .c files. This is focusedonly on removal (with minor fixups), further cleanups are possible butwill require doing the header files properly with forward declarations,minimized includes and include-what-you-use care.Reviewed-by: Josef Bacik Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

ee129330 - btrfs: add raid stripe tree definitions

Thu, 14 Sep 2023 16:06:56 +0000

btrfs: add raid stripe tree definitionsAdd definitions for the raid stripe tree. This tree will hold informationabout the on-disk layout of the stripes in a RAID set.Each stripe extent has a 1:1 relationship with an on-disk extent item andis doing the logical to per-drive physical address translation for theextent item in question.Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

150cce2d - btrfs: move extent_buffer::lock_owner to debug section

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

btrfs: move extent_buffer::lock_owner to debug sectionThe lock_owner is used for a rare corruption case and we haven't seenany reports in years. Move it to the debugging section of eb. To closethe holes also move log_index so the final layout looks like:struct extent_buffer { u64 start; /* 0 8 */ long unsigned int len; /* 8 8 */ long unsigned int bflags; /* 16 8 */ struct btrfs_fs_info * fs_info; /* 24 8 */ spinlock_t refs_lock; /* 32 4 */ atomic_t refs; /* 36 4 */ int read_mirror; /* 40 4 */ s8 log_index; /* 44 1 */ /* XXX 3 bytes hole, try to pack */ struct callback_head callback_head __attribute__((__aligned__(8))); /* 48 16 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct rw_semaphore lock; /* 64 40 */ struct page * pages[16]; /* 104 128 */ /* size: 232, cachelines: 4, members: 11 */ /* sum members: 229, holes: 1, sum holes: 3 */ /* forced alignments: 1, forced holes: 1, sum forced holes: 3 */ /* last cacheline: 40 bytes */} __attribute__((__aligned__(8)));This saves 8 bytes in total and still keeps the lock on a separate cacheline.Reviewed-by: Qu Wenruo Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.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/locking.c

5335f437 - btrfs: include trace header in where necessary

Fri, 25 Aug 2023 20:19:28 +0000

btrfs: include trace header in where necessaryIf we no longer include the tracepoints from ctree.h we fail to compilebecause we have the dependency in some of the header files and sourcefiles. Add the include where we have these dependencies to allow us toremove the include from ctree.h.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/locking.c

1a1b0e72 - btrfs: add block-group tree to lockdep classes

Wed, 31 May 2023 22:33:01 +0000

btrfs: add block-group tree to lockdep classesThe block group tree was not present among the lockdep classes. We couldget potentially lockdep warnings but so far none has been seen, alsobecause block-group-tree is a relatively new feature.CC: stable@vger.kernel.org # 6.1+Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

0b548539 - btrfs: locking: use atomic for DREW lock writers

Wed, 01 Mar 2023 20:47:08 +0000

btrfs: locking: use atomic for DREW lock writersThe DREW lock uses percpu variable to track lock counters and for thatit needs to allocate the structure. In btrfs_read_tree_root() orbtrfs_init_fs_root() this may add another error case or requires theNOFS scope protection.One way is to preallocate the structure as was suggested inhttps://lore.kernel.org/linux-btrfs/20221214021125.28289-1-robbieko@synology.com/We may avoid the allocation altogether if we don't use the percpuvariables but an atomic for the writer counter. This should not make anydifference, the DREW lock is used for truncate and NOCOW writes alongwith other IO operations.The percpu counter for writers has been there since the original commit8257b2dc3c1a1057 "Btrfs: introduce btrfs_{start, end}_nocow_write() foreach subvolume". The reason could be to avoid hammering the samecacheline from all the readers but then the writers do that anyway.Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.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/locking.c

857bc13f - btrfs: implement a nowait option for tree searches

Mon, 12 Sep 2022 19:27:42 +0000

btrfs: implement a nowait option for tree searchesFor NOWAIT IOCBs we'll need a way to tell search to not wait on locksor anything. Accomplish this by adding a path->nowait flag that willuse trylocks and skip reading of metadata, returning -EAGAIN in eitherof these cases. For now we only need this for reads, so only the readside is handled. Add an ASSERT() to catch anybody trying to use thisfor writes so they know they'll have to implement the write side.Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: Stefan Roesch Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

b40130b2 - btrfs: fix lockdep splat with reloc root extent buffers

Tue, 26 Jul 2022 20:24:04 +0000

btrfs: fix lockdep splat with reloc root extent buffersWe have been hitting the following lockdep splat with btrfs/187 recently WARNING: possible circular locking dependency detected 5.19.0-rc8+ #775 Not tainted ------------------------------------------------------ btrfs/752500 is trying to acquire lock: ffff97e1875a97b8 (btrfs-treloc-02#2){+.+.}-{3:3}, at: __btrfs_tree_lock+0x24/0x110 but task is already holding lock: ffff97e1875a9278 (btrfs-tree-01/1){+.+.}-{3:3}, at: __btrfs_tree_lock+0x24/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (btrfs-tree-01/1){+.+.}-{3:3}: down_write_nested+0x41/0x80 __btrfs_tree_lock+0x24/0x110 btrfs_init_new_buffer+0x7d/0x2c0 btrfs_alloc_tree_block+0x120/0x3b0 __btrfs_cow_block+0x136/0x600 btrfs_cow_block+0x10b/0x230 btrfs_search_slot+0x53b/0xb70 btrfs_lookup_inode+0x2a/0xa0 __btrfs_update_delayed_inode+0x5f/0x280 btrfs_async_run_delayed_root+0x24c/0x290 btrfs_work_helper+0xf2/0x3e0 process_one_work+0x271/0x590 worker_thread+0x52/0x3b0 kthread+0xf0/0x120 ret_from_fork+0x1f/0x30 -> #1 (btrfs-tree-01){++++}-{3:3}: down_write_nested+0x41/0x80 __btrfs_tree_lock+0x24/0x110 btrfs_search_slot+0x3c3/0xb70 do_relocation+0x10c/0x6b0 relocate_tree_blocks+0x317/0x6d0 relocate_block_group+0x1f1/0x560 btrfs_relocate_block_group+0x23e/0x400 btrfs_relocate_chunk+0x4c/0x140 btrfs_balance+0x755/0xe40 btrfs_ioctl+0x1ea2/0x2c90 __x64_sys_ioctl+0x88/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (btrfs-treloc-02#2){+.+.}-{3:3}: __lock_acquire+0x1122/0x1e10 lock_acquire+0xc2/0x2d0 down_write_nested+0x41/0x80 __btrfs_tree_lock+0x24/0x110 btrfs_lock_root_node+0x31/0x50 btrfs_search_slot+0x1cb/0xb70 replace_path+0x541/0x9f0 merge_reloc_root+0x1d6/0x610 merge_reloc_roots+0xe2/0x260 relocate_block_group+0x2c8/0x560 btrfs_relocate_block_group+0x23e/0x400 btrfs_relocate_chunk+0x4c/0x140 btrfs_balance+0x755/0xe40 btrfs_ioctl+0x1ea2/0x2c90 __x64_sys_ioctl+0x88/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that might help us debug this: Chain exists of: btrfs-treloc-02#2 --> btrfs-tree-01 --> btrfs-tree-01/1 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(btrfs-tree-01/1); lock(btrfs-tree-01); lock(btrfs-tree-01/1); lock(btrfs-treloc-02#2); *** DEADLOCK *** 7 locks held by btrfs/752500: #0: ffff97e292fdf460 (sb_writers#12){.+.+}-{0:0}, at: btrfs_ioctl+0x208/0x2c90 #1: ffff97e284c02050 (&fs_info->reclaim_bgs_lock){+.+.}-{3:3}, at: btrfs_balance+0x55f/0xe40 #2: ffff97e284c00878 (&fs_info->cleaner_mutex){+.+.}-{3:3}, at: btrfs_relocate_block_group+0x236/0x400 #3: ffff97e292fdf650 (sb_internal#2){.+.+}-{0:0}, at: merge_reloc_root+0xef/0x610 #4: ffff97e284c02378 (btrfs_trans_num_writers){++++}-{0:0}, at: join_transaction+0x1a8/0x5a0 #5: ffff97e284c023a0 (btrfs_trans_num_extwriters){++++}-{0:0}, at: join_transaction+0x1a8/0x5a0 #6: ffff97e1875a9278 (btrfs-tree-01/1){+.+.}-{3:3}, at: __btrfs_tree_lock+0x24/0x110 stack backtrace: CPU: 1 PID: 752500 Comm: btrfs Not tainted 5.19.0-rc8+ #775 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x56/0x73 check_noncircular+0xd6/0x100 ? lock_is_held_type+0xe2/0x140 __lock_acquire+0x1122/0x1e10 lock_acquire+0xc2/0x2d0 ? __btrfs_tree_lock+0x24/0x110 down_write_nested+0x41/0x80 ? __btrfs_tree_lock+0x24/0x110 __btrfs_tree_lock+0x24/0x110 btrfs_lock_root_node+0x31/0x50 btrfs_search_slot+0x1cb/0xb70 ? lock_release+0x137/0x2d0 ? _raw_spin_unlock+0x29/0x50 ? release_extent_buffer+0x128/0x180 replace_path+0x541/0x9f0 merge_reloc_root+0x1d6/0x610 merge_reloc_roots+0xe2/0x260 relocate_block_group+0x2c8/0x560 btrfs_relocate_block_group+0x23e/0x400 btrfs_relocate_chunk+0x4c/0x140 btrfs_balance+0x755/0xe40 btrfs_ioctl+0x1ea2/0x2c90 ? lock_is_held_type+0xe2/0x140 ? lock_is_held_type+0xe2/0x140 ? __x64_sys_ioctl+0x88/0xc0 __x64_sys_ioctl+0x88/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdThis isn't necessarily new, it's just tricky to hit in practice. Thereare two competing things going on here. With relocation we create asnapshot of every fs tree with a reloc tree. Any extent buffers thatget initialized here are initialized with the reloc root lockdep key.However since it is a snapshot, any blocks that are currently in cachethat originally belonged to the fs tree will have the normal treelockdep key set. This creates the lock dependency of reloc tree -> normal treefor the extent buffer locking during the first phase of the relocationas we walk down the reloc root to relocate blocks.However this is problematic because the final phase of the relocation ismerging the reloc root into the original fs root. This involvessearching down to any keys that exist in the original fs root and thenswapping the relocated block and the original fs root block. We have tosearch down to the fs root first, and then go search the reloc root forthe block we need to replace. This creates the dependency of normal tree -> reloc treewhich is why lockdep complains.Additionally even if we were to fix this particular mismatch with adifferent nesting for the merge case, we're still slotting in a blockthat has a owner of the reloc root objectid into a normal tree, so thatblock will have its lockdep key set to the tree reloc root, and create alockdep splat later on when we wander into that block from the fs root.Unfortunately the only solution here is to make sure we do not set thelockdep key to the reloc tree lockdep key normally, and then reset anyblocks we wander into from the reloc root when we're doing the merged.This solves the problem of having mixed tree reloc keys intermixed withnormal tree keys, and then allows us to make sure in the merge case wemaintain the lock order of normal tree -> reloc treeWe handle this by setting a bit on the reloc root when we do the searchfor the block we want to relocate, and any block we search into or COWat that point gets set to the reloc tree key. This works correctlybecause we only ever COW down to the parent node, so we aren't resettingthe key for the block we're linking into the fs root.With this patch we no longer have the lockdep splat in btrfs/187.Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

0a27a047 - btrfs: move lockdep class helpers to locking.c

Tue, 26 Jul 2022 20:24:03 +0000

btrfs: move lockdep class helpers to locking.cThese definitions exist in disk-io.c, which is not related to thelocking. Move this over to locking.h/c where it makes more sense.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/locking.c

97e86631 - btrfs: don't set lock_owner when locking extent buffer for reading

Thu, 09 Jun 2022 02:39:36 +0000

btrfs: don't set lock_owner when locking extent buffer for readingIn 196d59ab9ccc "btrfs: switch extent buffer tree lock to rw_semaphore"the functions for tree read locking were rewritten, and in the processthe read lock functions started setting eb->lock_owner = current->pid.Previously lock_owner was only set in tree write lock functions.Read locks are shared, so they don't have exclusive ownership of theunderlying object, so setting lock_owner to any single value for aread lock makes no sense. It's mostly harmless because write locksand read locks are mutually exclusive, and none of the existing codein btrfs (btrfs_init_new_buffer and print_eb_refs_lock) cares whatnonsense is written in lock_owner when no writer is holding the lock.KCSAN does care, and will complain about the data race incessantly.Remove the assignments in the read lock functions because they'reuseless noise.Fixes: 196d59ab9ccc ("btrfs: switch extent buffer tree lock to rw_semaphore")CC: stable@vger.kernel.org # 5.15+Reviewed-by: Nikolay Borisov Reviewed-by: Filipe Manana Signed-off-by: Zygo Blaxell Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c

1a9fd417 - btrfs: fix typos in comments

Fri, 21 May 2021 15:42:23 +0000

btrfs: fix typos in commentsFix typos that have snuck in since the last round. Found by codespell.Signed-off-by: David Sterba List of files: /linux-6.15/fs/btrfs/locking.c