Project

General

Profile

Bug #6045

zfs_mount(MS_REMOUNT) is unsafe

Added by Andriy Gapon about 5 years ago. Updated about 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2015-07-02
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

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.

History

#1

Updated by Andriy Gapon about 5 years ago

Clarification: z_teardown_lock lock should be taken in the writer / exclusive mode.

#2

Updated by Andriy Gapon about 5 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.

Also available in: Atom PDF