Bug #6045
openzfs_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 almost 7 years ago
Clarification: z_teardown_lock
lock should be taken in the writer / exclusive mode.
Updated by Andriy Gapon over 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.