Page MenuHomeFreeBSD

VOP_INACTIVE(9): clarify wording
ClosedPublic

Authored by asomers on Mar 15 2019, 4:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 4 2023, 10:40 AM
Unknown Object (File)
Dec 3 2023, 5:29 PM
Unknown Object (File)
Nov 16 2023, 8:28 AM
Unknown Object (File)
Nov 12 2023, 7:45 AM
Unknown Object (File)
Nov 9 2023, 5:55 PM
Unknown Object (File)
Nov 7 2023, 3:42 PM
Unknown Object (File)
Nov 7 2023, 11:32 AM
Unknown Object (File)
Oct 24 2023, 7:47 PM
Subscribers

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 23117
Build 22171: arc lint + arc unit

Event Timeline

I believe a note that VOP_INACTIVE() call is not guaranteed is also due.

This revision is now accepted and ready to land.Mar 15 2019, 4:35 PM

Add note that there is no guarantee that VOP_INACTIVE will be called

This revision now requires review to proceed.Mar 15 2019, 4:38 PM
0mp added a subscriber: 0mp.

ok from manpages

This revision is now accepted and ready to land.Mar 15 2019, 5:25 PM
share/man/man9/VOP_INACTIVE.9
61

I do not know what unclean unmounts are. It is not guaranteed to be called because e.g. it might be called while only owning a shared vnode lock, and non-sleeping upgrade failed due to other shared lockers.

Respond to kib's criticism

This revision now requires review to proceed.Mar 15 2019, 5:40 PM
share/man/man9/VOP_INACTIVE.9
53

This seems a little less clear than before; it could be interpreted as "may be called sometimes when the kernel is still using the vnode."

I might leave this sentence alone, but bring up your "no guarantee" sentence to follow directly after it.

60–61

Hm, can you clarify this sentence? It's called as part of vgonel() even during forced umount. So what is an unclean unmount in this context?

share/man/man9/VOP_INACTIVE.9
61

@kib, which path would a VOP_INACTIVE() caller only hold a shared lock?

asomers added inline comments.
share/man/man9/VOP_INACTIVE.9
60–61

I meant things like power loss, crash, etc. The filesystem musn't rely exclusively on VOP_INACTIVE to reclaim space in such cases.

share/man/man9/VOP_INACTIVE.9
61

Oh, vput/vunref may have a failed lock upgrade. But they still set VI_OWEINACT, so eventually the last other holder should invoke VOP_INACTIVE (or vgonel will).

share/man/man9/VOP_INACTIVE.9
60–61

We generally only document API guarantees with the understanding that they only apply if power is consistent and the system does not crash. If we added boilerplate about power loss/crash to every API it would bloat the manuals excessively and make it more difficult to read relevant information.

I don't think there's any particular reason these APIs are different in that respect.

share/man/man9/VOP_INACTIVE.9
61

The vnode could be vref-ed while VI_OWEINACT is set, and then if the lock mode is shared, it is still not inactivated. So no, there is no guarantee that vop_inactive necessary called before reclaim.

61

'while the vnode lock could not be upgraded to exclusive without sleeping'.

asomers marked an inline comment as done.

Use kib's preferred wording.

share/man/man9/VOP_INACTIVE.9
61

The vnode could be vref-ed while VI_OWEINACT is set, and then if the lock mode is shared, it is still not inactivated. So no, there is no guarantee that vop_inactive necessary called before reclaim.

I don't follow. If it is vrefed, it gains a non-zero usecount and is marked VI_ACTIVE. In vgonel(), it will still be vinactive -> VOP_INACTIVE()ed before RECLAIM.

share/man/man9/VOP_INACTIVE.9
61

VOP_INACTIVE() gerald is to be called on each v_usecount 1->0 transition. This is not guaranteed at least due to the shared locking.

The fact that we might be calling VOP_INACTIVE on next round of 1->0 transition or right before VOP_RECLAIM() call in vgonel() still does not satisfy the promise of calling VOP_INACTIVE on previous v_usecount zeroing.

This revision is now accepted and ready to land.Mar 15 2019, 6:46 PM
This revision was automatically updated to reflect the committed changes.