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

btrfs: simplify waiting loop in btrfs_tree_lock

2019-02-25T13:13:28Z

Currently, the number of readers and writers is checked and in case there are any, wait and redo the locks. There's some duplication before the branches go back to again label, eg. calling wait_event on blocking_readers twice. The sequence is transformed loop: * wait for readers * wait for writers * write_lock * check readers, unlock and wait for readers, loop * check writers, unlock and wait for writers, loop The new sequence is not exactly the same due to the simplification, for readers it's slightly faster. For the writers, original code does * wait for writers * (loop) wait for readers * wait for writers -- again while the new goes directly to the reader check. This should behave the same on a contended lock with multiple writers and readers, but can reduce number of times we're waiting on something. 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 waitqueue_actvie with cond_wake_up

2018-05-28T16:23:09Z

Use the wrappers and reduce the amount of low-level details about the waitqueue management. Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba

btrfs: replace GPL boilerplate by SPDX -- sources

2018-04-12T14:29:51Z

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

btrfs: Relax memory barrier in btrfs_tree_unlock

2018-03-30T23:26:51Z

When performing an unlock on an extent buffer we'd like to order the decrement of extent_buffer::blocking_writers with waking up any waiters. In such situations it's sufficient to use smp_mb__after_atomic rather than the heavy smp_mb. On architectures where atomic operations are fully ordered (such as x86 or s390) unconditionally executing a heavyweight smp_mb instruction causes a severe hit to performance while bringin no improvements in terms of correctness. The better thing is to use the appropriate smp_mb__after_atomic routine which will do the correct thing (invoke a full smp_mb or in the case of ordered atomics insert a compiler barrier). Put another way, an RMW atomic op + smp_load__after_atomic equals, in terms of semantics, to a full smp_mb. This ensures that none of the problems described in the accompanying comment of waitqueue_active occur. No functional changes. Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: cleanup, remove stray return statements

2016-01-07T13:30:52Z

Signed-off-by: David Sterba

btrfs: comment the rest of implicit barriers before waitqueue_active

2015-10-10T16:42:00Z

There are atomic operations that imply the barrier for waitqueue_active mixed in an if-condition. Signed-off-by: David Sterba

btrfs: add comments to barriers before waitqueue_active

2015-10-10T16:40:04Z

Reduce number of undocumented barriers out there. Signed-off-by: David Sterba

btrfs: Add WARN_ON() for double lock in btrfs_tree_lock()

2015-08-09T14:07:14Z

When a task trying to double lock a extent buffer, there are no lockdep warning about it because this lock may be in "blocking_lock" state, and make us hard to debug. This patch add a WARN_ON() for above condition, it can not report all deadlock cases(as lock between tasks), but at least helps us some. Signed-off-by: Zhao Lei Signed-off-by: Chris Mason