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 <dste...@suse.com>

 Thanks for cleaning volume_mutex.

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

Anand

--
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