kernel/fs/btrfs/locking.h, branch linux-5.1.y

btrfs: merge btrfs_set_lock_blocking_rw with it's caller

2019-02-25T13:13:28Z

The last caller that does not have a fixed value of lock is btrfs_set_path_blocking, that actually does the same conditional swtich by the lock type so we can merge the branches together and remove the helper. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba

btrfs: open code now trivial btrfs_set_lock_blocking

2019-02-25T13:13:27Z

btrfs_set_lock_blocking is now only a simple wrapper around btrfs_set_lock_blocking_write. The name does not bring any semantic value that could not be inferred from the new function so there's no point keeping it. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba

btrfs: replace btrfs_set_lock_blocking_rw with appropriate helpers

2019-02-25T13:13:27Z

We can use the right helper where the lock type is a fixed parameter. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba

btrfs: split btrfs_clear_lock_blocking_rw to read and write helpers

2019-02-25T13:13:27Z

There are many callers that hardcode the desired lock type so we can avoid the switch and call them directly. Split the current function to two. There are no remaining users of btrfs_clear_lock_blocking_rw so it's removed. The call sites will be converted in followup patches. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba

btrfs: split btrfs_set_lock_blocking_rw to read and write helpers

2019-02-25T13:13:27Z

There are many callers that hardcode the desired lock type so we can avoid the switch and call them directly. Split the current function to two but leave a helper that still takes the variable lock type to make current code compile. The call sites will be converted in followup patches. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba

btrfs: replace GPL boilerplate by SPDX -- headers

2018-04-12T14:29:46Z

Remove GPL boilerplate text (long, short, one-line) and keep the rest, ie. personal, company or original source copyright statements. Add the SPDX header. Unify the include protection macros to match the file names. Signed-off-by: David Sterba

btrfs: fix lockups from btrfs_clear_path_blocking

2014-11-19T18:34:35Z

The fair reader/writer locks mean that btrfs_clear_path_blocking needs to strictly follow lock ordering rules even when we already have blocking locks on a given path. Before we can clear a blocking lock on the path, we need to make sure all of the locks have been converted to blocking. This will remove lock inversions against anyone spinning in write_lock() against the buffers we're trying to get read locks on. These inversions didn't exist before the fair read/writer locks, but now we need to be more careful. We papered over this deadlock in the past by changing btrfs_try_read_lock() to be a true trylock against both the spinlock and the blocking lock. This was slower, and not sufficient to fix all the deadlocks. This patch adds a btrfs_tree_read_lock_atomic(), which basically means get the spinlock but trylock on the blocking lock. Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Reported-by: Patrick Schmid cc: stable@vger.kernel.org #v3.15+

Btrfs: remove btrfs_try_spin_lock

2013-03-14T18:57:10Z

Remove a useless function declaration Signed-off-by: Liu Bo Signed-off-by: Josef Bacik Signed-off-by: Chris Mason

btrfs: return void in functions without error conditions

2012-03-22T00:45:34Z

Signed-off-by: Jeff Mahoney

Btrfs: switch the btrfs tree locks to reader/writer

2011-07-27T16:46:46Z

The btrfs metadata btree is the source of significant lock contention, especially in the root node. This commit changes our locking to use a reader/writer lock. The lock is built on top of rw spinlocks, and it extends the lock tracking to remember if we have a read lock or a write lock when we go to blocking. Atomics count the number of blocking readers or writers at any given time. It removes all of the adaptive spinning from the old code and uses only the spinning/blocking hints inside of btrfs to decide when it should continue spinning. In read heavy workloads this is dramatically faster. In write heavy workloads we're still faster because of less contention on the root node lock. We suffer slightly in dbench because we schedule more often during write locks, but all other benchmarks so far are improved. Signed-off-by: Chris Mason