]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: don't set lock_owner when locking extent buffer for reading
authorZygo Blaxell <ce3g8jdj@umail.furryterror.org>
Thu, 9 Jun 2022 02:39:36 +0000 (22:39 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 29 Jun 2022 07:03:27 +0000 (09:03 +0200)
commit7faa199eec1ec76d6e5e6574d83d0a72fa312053
tree719ab306a3063012af64a1fcd34701a327e4979e
parentdc6e5d0b7b1a920e3eb8860b7a7ceb2ab2dcdf6d
btrfs: don't set lock_owner when locking extent buffer for reading

commit 7a6e319ac0875c199fc4f728528ba8db0a16c17f upstream.

In 731044a98001 "btrfs: switch extent buffer tree lock to rw_semaphore"
the functions for tree read locking were rewritten, and in the process
the 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 the
underlying object, so setting lock_owner to any single value for a
read lock makes no sense.  It's mostly harmless because write locks
and read locks are mutually exclusive, and none of the existing code
in btrfs (btrfs_init_new_buffer and print_eb_refs_lock) cares what
nonsense 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're
useless noise.

Fixes: 731044a98001 ("btrfs: switch extent buffer tree lock to rw_semaphore")
CC: stable@vger.kernel.org # 5.15+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/locking.c