On Fri, Apr 13, 2018 at 01:30:22PM +0800, Anand Jain wrote:
> 
> 
> > @@ -4569,8 +4560,10 @@ static long btrfs_ioctl_balance(struct file *file, 
> > void __user *arg)
> >             /* this is either (2) or (3) */
> >             if (!atomic_read(&fs_info->balance_running)) {
> >                     mutex_unlock(&fs_info->balance_mutex);
> > -                   if (!mutex_trylock(&fs_info->volume_mutex))
> > -                           goto again;
> 
> 
> > +                   /*
> > +                    * Lock released to allow other waiters to continue,
> > +                    * we'll reexamine the status again.
> > +                    */
> 
>   I wonder if there was any case where performing the unlock and lock
>   sequence on the balance_mutex has helped?

It might help in cases something is waiting on the balance mutex, like
reading status, calling pause in parallel, but I doubt that it has some
significant impact.

>   Otherwise IMO we can clean this up as well. It looks like this sequence
>   was needed only to acquire the volume_mutex.

Agreed and I probably had removed in some early versions of the patch,
but this needs to be considered separately from volume_mutex so this
patch preserves the code though it's likely not needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to