Page MenuHomeFreeBSD

vfs: add MNT_VNODE_FOREACH_ACTIVE_FILTER
AbandonedPublic

Authored by mjg on Dec 5 2019, 2:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 14 2024, 5:18 AM
Unknown Object (File)
Dec 26 2023, 5:07 AM
Unknown Object (File)
Dec 22 2023, 10:00 PM
Unknown Object (File)
Nov 26 2023, 10:29 PM
Unknown Object (File)
Nov 25 2023, 10:02 AM
Unknown Object (File)
Nov 22 2023, 11:03 AM
Unknown Object (File)
Nov 22 2023, 9:51 AM
Unknown Object (File)
Nov 22 2023, 9:50 AM
Subscribers

Details

Reviewers
jeff
kib
Summary

The current iterator always ends up taking the interlock without letting the caller decide if it wants to do anything with the vnode upfront. In particular vfs_msync tends to not need to do anything.

This functionality is motivated by a different (to be proposed) patch which will end up adding vnodes to the active list.

The use in vfs_msync will be committed separately. Note the checks are now duplicated but will become useful with further patches and I don't think removing this right now adds much benefit.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 27980

Event Timeline

sys/kern/vfs_subr.c
4344

The racy unlocked check is fine since obj is type-stable.

The cases that I looked at could be solved by using vhold() instead of the interlock. In the case that you're already iterating over the active list, you know you don't have to activate the vnode. You should be able to return it with an atomic increment of the hold count and let the caller vdrop. For most callers this is sufficient. For UFS where it wants to dig around in the inode it may need to acquire the vnode interlock to prevent races with RECLAIM().

ufs_inode would actually make a good use case for uma_smr. It would eliminate some interlock activity.

sys/kern/vfs_subr.c
4344

Please add a comment documenting that you require the type stability of vm objects here. There has been discussion around resolving these cases.

Note the entire point of introduction of filtering is to use it later to sort out VI_DEFERRED vnodes in stable/12. Clearing the flag would require taking the interlock anyway. Moreover I don't expect this macro in this form to survive in the long term in head either. Thus I don't think proposed change is of use, at least not in the first cut in the tree.

sys/kern/vfs_subr.c
4344

ok