diff options
| author | Omar Sandoval <[email protected]> | 2018-05-22 00:07:19 +0000 |
|---|---|---|
| committer | David Sterba <[email protected]> | 2018-05-28 16:24:13 +0000 |
| commit | 37becec95ac31b209eb1c8e096f1093a7db00f32 (patch) | |
| tree | 87dc9ed68fd8336c81d16e5edc2e3e19bcb39f28 /fs/btrfs/tests/extent-buffer-tests.c | |
| parent | btrfs: fix describe_relocation when printing unknown flags (diff) | |
| download | kernel-37becec95ac31b209eb1c8e096f1093a7db00f32.tar.gz kernel-37becec95ac31b209eb1c8e096f1093a7db00f32.zip | |
Btrfs: allow empty subvol= again
I got a report that after upgrading to 4.16, someone's filesystems
weren't mounting:
[ 23.845852] BTRFS info (device loop0): unrecognized mount option 'subvol='
Before 4.16, this mounted the default subvolume. It turns out that this
empty "subvol=" is actually an application bug, but it was causing the
application to fail, so it's an ABI break if you squint.
The generic parsing code we use for mount options (match_token())
doesn't match an empty string as "%s". Previously, setup_root_args()
removed the "subvol=" string, but the mount path was cleaned up to not
need that. Add a dummy Opt_subvol_empty to fix this.
The simple workaround is to use / or . for the value of 'subvol=' .
Fixes: 312c89fbca06 ("btrfs: cleanup btrfs_mount() using btrfs_mount_root()")
CC: [email protected] # 4.16+
Signed-off-by: Omar Sandoval <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'fs/btrfs/tests/extent-buffer-tests.c')
0 files changed, 0 insertions, 0 deletions