VOP_RECLAIM naturally has exclusive access to the vnode, so having it
locked on entry is not strictly necessary -- but it means if there
are any final operations that must be done on the vnode, such as
ffs_update, requiring exclusive access to it, we can now kassert that
the vnode is locked in those operations.
We can't just have the caller release the last lock because some file
systems don't use genfs_lock, and require the vnode to remain valid
for VOP_UNLOCK to work, notably unionfs.
- move the syncer into kern/vfs_subr.c.
- change the syncer to process the mountlist and VFS_SYNC as appropriate.
- use an API for mount points similiar to the API for vnodes:
- vfs_syncer_add_to_worklist(struct mount *mp) to add
- vfs_syncer_remove_from_worklist(struct mount *mp) to remove a mount.
No objections on tech-kern@
find.
The filesystem ones all call genfs_eopnotsupp - right now I am only
implementing the plumbing and we can implement fallocate and/or
fdiscard for files later.
The device ones call spec_fallocate (which is also genfs_eopnotsupp)
and spec_fdiscard, which dispatches to the device-level op.
The fifo ones all call vn_fifo_bypass, which also ends up being
EOPNOTSUPP.
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
the vnode operations vector for active vnodes is unsafe because it
is not known whether deadfs or the original file system will be
called.
- Pass down LK_RETRY to the lock operation (hint for deadfs only).
- Change deadfs lock operation to return ENOENT if LK_RETRY is unset.
- Change all other lock operations to check for dead vnode once
the vnode is locked and unlock and return ENOENT in this case.
With these changes in place vnode lock operations will never succeed
after vclean() has marked the vnode as VI_XLOCK and before vclean()
has changed the operations vector.
Adresses PR kern/37706 (Forced unmount of file systems is unsafe)
Discussed on tech-kern.
Welcome to 6.99.33
- fix writing to coda files. this is probably not the right way to do
this, but it satisfies the locking protocol:
1. Sometimes coda_open() is called with an unlocked vnode which
does not satisfy the locking protocol. Lock it for now. We
need to find out why this happens
2. VFS_VGET sometimes returns the container vnode unlocked. What
is the locking protocol for VFS_VGET? We also lock it here.
maya