On 20.06.2018 20:51, David Sterba wrote: > This patchset fixes the bugs recently reported by syzbot. I've tried to > use patches from Anand [1] to fix that but in the end there were fixes > not suitable for merging to 4.18 and my final fix took a different > approach. > > In short, fs_devices::opened is protected by uuid_mutex and this mutex > can be used to exclude mount and scanning to interfere. > > The fstests pass and 2 syzbot reproducers reported no problems. I'd like > to push the patchset to 4.18 but not rc2 as it's too close. I'll add the > patchset to for-next soon if there are no major problems found, but > otherwise I'm open to comments. > > [1] > https://patchwork.kernel.org/patch/10446779/ > https://patchwork.kernel.org/patch/10437707/ 1-6 > > David Sterba (7): > btrfs: restore uuid_mutex in btrfs_open_devices > btrfs: extend critical section when scanning a new device > btrfs: lift uuid_mutex to callers of btrfs_scan_one_device > btrfs: lift uuid_mutex to callers of btrfs_open_devices > btrfs: lift uuid_mutex to callers of btrfs_parse_early_options > btrfs: reorder initialization before the mount locks uuid_mutex > btrfs: fix mount and ioctl device scan ioctl race > > fs/btrfs/super.c | 38 +++++++++++++++++++++++++------------- > fs/btrfs/volumes.c | 11 ++++++----- > 2 files changed, 31 insertions(+), 18 deletions(-) > It's good you've added lockdep asserts in functions whose locking is lifted to the caller. However, I'm a bit hesitant about extending the locking section so much. I.e i parse_early_opt you are covering quite some string manipulation functionality and only the single call to btrfs_scan_one_device. I wonder if the whole device scanning/mounting code could be refactored to not rely on 2 locks (device list mutex + uuid mutex, and that's after you merged your series refactoring locking). Anyways, the series LGTM: Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
