Re: [PATCH 11/16] btrfs: kill btrfs_fs_info::volume_mutex

[Anand Jain <anand.jain@oracle.com>]

On 04/04/2018 02:34 AM, David Sterba wrote:
> Mutual exclusion of device add/rm and balance was done by the volume
> mutex up to version 3.7. The commit 5ac00addc7ac091109 ("Btrfs: disallow
> mutually exclusive admin operations from user mode") added a bit that
> essentially tracked the same information.
> 
> The status bit has an advantage over a mutex that it can be set without
> restrictions of function context, so it started to be used in the
> mount-time resuming of balance or device replace.
> 
> But we don't really need to track the same information in two ways.
> 
> 1) After the previous cleanups, the main ioctl handlers for
>     add/del/resize copy the EXCL_OP bit next to the volume mutex, here
>     it's clearly safe.
> 
> 2) Resuming balance during mount or after rw remount will set only the
>     EXCL_OP bit and the volume_mutex is held in the kernel thread that
>     calls btrfs_balance.
> 
> 3) Resuming device replace during mount or after rw remount is done
>     after balance and is excluded by the EXCL_OP bit. It does not take
>     the volume_mutex at all and completely relies on the EXCL_OP bit.
> 
> 4) The resuming of balance and dev-replace cannot hapen at the same time
>     as the ioctls cannot be started in parallel. Nevertheless, a crafted
>     image could trigger that and a warning is printed.
> 
> 5) Balance is normally excluded by EXCL_OP and also uses own mutex to
>     protect against concurrent access to its status data. There's some
>     trickery to maintain the right lock nesting in case we need to
>     reexamine the status in btrfs_ioctl_balance. The volume_mutex is
>     removed and the unlock/lock sequence is left in place as we might
>     expect other waiters to proceed.
> 
> 6) Similar to 5, the unlock/lock sequence is kept in
>     btrfs_cancel_balance to allow waiters to continue. >
> Signed-off-by: David Sterba <dsterba@suse.com>

  Thanks for cleaning volume_mutex.

  Reviewed-by: Anand Jain <anand.jain@oracle.com>

Anand