3/3 vfs: refactor vputx and add more comments
ClosedPublic
Actions

Authored by mjg on Feb 6 2020, 12:20 AM.

Details

Reviewers

kib
jeff

Commits

rS357812: vfs: refactor vputx and add more comment

Summary

the vnode interlock relocking for vchr in vrele may seem problematic, but it almost never happens in practice. I take it for readability.

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

mjg retitled this revision from vfs: refactor vputx and add more comments to 3/3 vfs: refactor vputx and add more comments.Feb 6 2020, 12:20 AM

mjg edited the summary of this revision. (Show Details)

tested by pho

sys/kern/vfs_subr.c
3200 ↗	(On Diff #67846)	Can we rename this vput_final or vput_last or something. At first glance it was confusing to me for historical reasons.
3327 ↗	(On Diff #67846)	It's not clear to me why all of the release routines don't have this VCHR code.

sys/kern/vfs_subr.c
2802–2804 ↗	(On Diff #67846)	The caller is required to hold the interlock when transitioning a VCHR usecount to zero. This prevents a race with devfs_reclaim_vchr() that would leak a si_usecount reference. The vnode lock will also prevent this race if it is held while dropping the last ref.
2810 ↗	(On Diff #67846)	vrele() decr v_usecount
2812 ↗	(On Diff #67846)	v_usecount == 0, does not decrement si_usecount v_rdev = NULL
2817 ↗	(On Diff #67846)	v_decr_devcount() v_dev == NULL, does not decrement si_usecount