diff options
author | Omar Sandoval <osandov@fb.com> | 2018-05-22 02:07:19 +0200 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2018-05-28 18:24:13 +0200 |
commit | 37becec95ac31b209eb1c8e096f1093a7db00f32 (patch) | |
tree | 87dc9ed68fd8336c81d16e5edc2e3e19bcb39f28 /sound/pci/trident | |
parent | btrfs: fix describe_relocation when printing unknown flags (diff) | |
download | linux-37becec95ac31b209eb1c8e096f1093a7db00f32.tar.xz linux-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: stable@vger.kernel.org # 4.16+
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'sound/pci/trident')
0 files changed, 0 insertions, 0 deletions