public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: don't set lock_owner when locking tree pages for reading
Date: Thu, 9 Jun 2022 10:42:28 +0100	[thread overview]
Message-ID: <20220609094228.GA3668047@falcondesktop> (raw)
In-Reply-To: <20220609023936.6112-1-ce3g8jdj@umail.furryterror.org>

On Wed, Jun 08, 2022 at 10:39:36PM -0400, Zygo Blaxell wrote:
> In 196d59ab9ccc "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: 196d59ab9ccc ("btrfs: switch extent buffer tree lock to rw_semaphore")
> Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>


Looks good to me.
Btw, the subject is misleading, the part "when locking tree pages" gives
the idea that it's about page locks, but what we are locking is an extent
buffer, so it should read like "... when locking extent buffer for reading".
Thanks.

Reviewed-by: Filipe Manana <fdmanana@suse.com>

> ---
>  fs/btrfs/locking.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
> index 313d9d685adb..33461b4f9c8b 100644
> --- a/fs/btrfs/locking.c
> +++ b/fs/btrfs/locking.c
> @@ -45,7 +45,6 @@ void __btrfs_tree_read_lock(struct extent_buffer *eb, enum btrfs_lock_nesting ne
>  		start_ns = ktime_get_ns();
>  
>  	down_read_nested(&eb->lock, nest);
> -	eb->lock_owner = current->pid;
>  	trace_btrfs_tree_read_lock(eb, start_ns);
>  }
>  
> @@ -62,7 +61,6 @@ void btrfs_tree_read_lock(struct extent_buffer *eb)
>  int btrfs_try_tree_read_lock(struct extent_buffer *eb)
>  {
>  	if (down_read_trylock(&eb->lock)) {
> -		eb->lock_owner = current->pid;
>  		trace_btrfs_try_tree_read_lock(eb);
>  		return 1;
>  	}
> @@ -90,7 +88,6 @@ int btrfs_try_tree_write_lock(struct extent_buffer *eb)
>  void btrfs_tree_read_unlock(struct extent_buffer *eb)
>  {
>  	trace_btrfs_tree_read_unlock(eb);
> -	eb->lock_owner = 0;
>  	up_read(&eb->lock);
>  }
>  
> -- 
> 2.30.2
> 

  parent reply	other threads:[~2022-06-09  9:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09  2:39 [PATCH] btrfs: don't set lock_owner when locking tree pages for reading Zygo Blaxell
2022-06-09  5:03 ` Nikolay Borisov
2022-06-09  9:42 ` Filipe Manana [this message]
2022-06-13 18:48 ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220609094228.GA3668047@falcondesktop \
    --to=fdmanana@kernel.org \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox