aboutsummaryrefslogtreecommitdiff
path: root/sys/fs/msdosfs
diff options
context:
space:
mode:
authorKonstantin Belousov <kib@FreeBSD.org>2019-08-29 07:50:25 +0000
committerKonstantin Belousov <kib@FreeBSD.org>2019-08-29 07:50:25 +0000
commit6470c8d3db6d04a44682b6cc898d446dcccc0ef0 (patch)
tree2fc4324bd522bff392719980dcc1108071541a16 /sys/fs/msdosfs
parent16040222487c9205dc23926f74ecd020858bd803 (diff)
downloadsrc-6470c8d3db6d04a44682b6cc898d446dcccc0ef0.tar.gz
src-6470c8d3db6d04a44682b6cc898d446dcccc0ef0.zip
Rework v_object lifecycle for vnodes.
Current implementation of vnode_create_vobject() and vnode_destroy_vobject() is written so that it prepared to handle the vm object destruction for live vnode. Practically, no filesystems use this, except for some remnants that were present in UFS till today. One of the consequences of that model is that each filesystem must call vnode_destroy_vobject() in VOP_RECLAIM() or earlier, as result all of them get rid of the v_object in reclaim. Move the call to vnode_destroy_vobject() to vgonel() before VOP_RECLAIM(). This makes v_object stable: either the object is NULL, or it is valid vm object till the vnode reclamation. Remove code from vnode_create_vobject() to handle races with the parallel destruction. Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D21412
Notes
Notes: svn path=/head/; revision=351598
Diffstat (limited to 'sys/fs/msdosfs')
-rw-r--r--sys/fs/msdosfs/msdosfs_denode.c4
1 files changed, 0 insertions, 4 deletions
diff --git a/sys/fs/msdosfs/msdosfs_denode.c b/sys/fs/msdosfs/msdosfs_denode.c
index 19ba40fed97f..858cf1b58908 100644
--- a/sys/fs/msdosfs/msdosfs_denode.c
+++ b/sys/fs/msdosfs/msdosfs_denode.c
@@ -552,10 +552,6 @@ msdosfs_reclaim(struct vop_reclaim_args *ap)
#endif
/*
- * Destroy the vm object and flush associated pages.
- */
- vnode_destroy_vobject(vp);
- /*
* Remove the denode from its hash chain.
*/
vfs_hash_remove(vp);