freebsd-nq/sys/cddl
Andriy Gapon e881d8757c remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat
On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that
manipulate mnt_ref.  But the job of properly maintaining the reference
count is already automatically performed by insmntque(9) and
delmntque(9).  So, in effect all ZFS vnodes referenced the corresponding
mountpoint twice.

That was completely harmless, but we want to be very explicit about what
FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF
provide quite different guarantees with respect to the held vfs_t /
mountpoint.  On illumos VFS_HOLD is sufficient to guarantee that
vfs_t.vfs_data stays valid.  On the other hand, on FreeBSD MNT_REF does
*not* provide the same guarantee about mnt_data.  We have to use
vfs_busy() to get that guarantee.

Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed.
VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers.

And because vfs_busy has a richer interface that can not be dumbed down
in all cases it's better to explicitly use it rather than trying to mask
it behind VFS_HOLD.

This change fixes a panic that could result from a race between
zfs_umount() and zfs_ioc_rollback().  We observed a case where
zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still
using.  That happened because there was nothing to prevent unmounting of
a ZFS filesystem that was in between zfs_suspend_fs() and
zfs_resume_fs().

Reviewed by:	kib, smh
MFC after:	3 weeks
Sponsored by:	ClusterHQ
Differential Revision: https://reviews.freebsd.org/D2794
2016-04-02 16:25:46 +00:00
..
boot/zfs Fix const conversion warning in lz4_decompress 2016-01-06 20:28:09 +00:00
compat/opensolaris remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat 2016-04-02 16:25:46 +00:00
contrib/opensolaris remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat 2016-04-02 16:25:46 +00:00
dev Remove unused variables dtrace_in_probe and dtrace_in_probe_addr. 2016-03-17 18:55:54 +00:00