Bug #6045
open
zfs_mount(MS_REMOUNT) is unsafe
0%
Description
zfs_mount(MS_REMOUNT) calls zfs_unregister_callbacks() + zfs_register_callbacks() without any synchronization with other activity.
Because of that concurrent ZPL operations may see the filesystem in an inconsistent state.
Another problem is that zfs_suspend_fs() and zfs_resume_fs() also unregister and re-register the callbacks and that can race with zfs_mount(MS_REMOUNT) when, for example, there is a concurrent zfs receive or rollback operation.
Since zfs_mount(MS_REMOUNT) performs a subset of zfsvfs_teardown() + zfsvfs_setup() operations it would make sense to guard the former with z_teardown_lock.
That would take care of both the concurrent I/O and the concurrent suspend / resume operations.
Updated by Andriy Gapon about 6 years ago
Clarification: z_teardown_lock lock should be taken in the writer / exclusive mode.
Updated by Andriy Gapon almost 6 years ago
Please be ware of the following problem https://svnweb.freebsd.org/base?view=revision&revision=286985
Summary: there could be a deadlock involving z_teardown_lock and spa_namespace_lock.dsl_prop_get_integer() takes spa_namespace_lock, at the same time spa_config_sync() calls into VFS->ZPL while holding spa_namespace_lock.
Not sure if my fix for FreeBSD is the best of what can be done to avoid the deadlock.
I feel that calling into ZPL while holding spa_namespace_lock is fragile in general.