Date: Wed, 13 Dec 2006 04:12:57 +0000 (UTC) From: Tor Egge <Tor.Egge@cvsup.no.freebsd.org> To: kostikbel@gmail.com Cc: freebsd-stable@freebsd.org, bde@zeta.org.au, freebsd-current@freebsd.org, ssouhlal@freebsd.org, V.Haisman@sh.cvut.cz, bde@freebsd.org Subject: Re: kqueue LOR Message-ID: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> In-Reply-To: <20061212135251.GJ311@deviant.kiev.zoral.com.ua> References: <20061212101903.GF311@deviant.kiev.zoral.com.ua> <20061212220705.F57430@delplex.bde.org> <20061212135251.GJ311@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061213.041257.74683466.Tor.Egge>