Re: kqueue LOR

> 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