Re: [PATCH 05/12] btrfs: remove useless mutex lock/unlock sequences

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Excerpts from Tsutomu Itoh's message of 2011-04-25 02:25:58 -0400:
> (2011/04/22 18:41), David Sterba wrote:
> > Signed-off-by: David Sterba <dsterba@xxxxxxx>
> > ---
> >  fs/btrfs/extent-tree.c |    6 ------
> >  1 files changed, 0 insertions(+), 6 deletions(-)
> > 
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> > index 31f33ba..c97ceab 100644
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -756,8 +756,6 @@ again:
> >  
> >              btrfs_release_path(root->fs_info->extent_root, path);
> >  
> > -            mutex_lock(&head->mutex);
> > -            mutex_unlock(&head->mutex);
> >              btrfs_put_delayed_ref(&head->node);
> >              goto again;
> 
> This code tests whether the mutex_lock can be acquired, and when the
> mutex_lock can be taken, it try again.
> So I think that it is not a meaningless code.

Correct, this code is waiting for the current lock holder to finish.
It's not exactly pretty but it needs to stay.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux