kqueue LOR
Tor Egge
Tor.Egge at cvsup.no.freebsd.org
Tue Dec 12 20:13:53 PST 2006
> Hmm, may be, since vnode must be interlocked by ffs_sync() after
> MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not
> needed in ufs_itimes.
>
> Tor ?
If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe to set
IN_MODIFIED in ufs_itimes() since the file system might be suspended or in the
process of being suspended with the vnode sync loop in ffs_sync() having
iterated past the vnode.
I don't think the mount interlock is needed to check for MNTK_SUSPEND being set
in ufs_itimes() as long as the vnode interlock is held. If a stale value is
read without MNTK_SUSPEND set then the vnode sync loop in ffs_sync() cannot
have iterated past the vnode, thus it should still be safe to set IN_MODIFIED.
All writes by the CPU performing the vnode sync loop before it released the
vnode interlock for the same vnode should be visible to the CPU in ufs_itimes()
after it has obtained the vnode interlock.
- Tor Egge
More information about the freebsd-current
mailing list