Date: Wed, 13 Dec 2006 16:39:55 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Tor Egge <Tor.Egge@cvsup.no.freebsd.org> 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: <20061213143955.GM311@deviant.kiev.zoral.com.ua> In-Reply-To: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> References: <20061212101903.GF311@deviant.kiev.zoral.com.ua> <20061212220705.F57430@delplex.bde.org> <20061212135251.GJ311@deviant.kiev.zoral.com.ua> <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--DfnuYBTqzt7sVGu3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 13, 2006 at 04:12:57AM +0000, Tor Egge wrote:
> > 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.
> >=20
> > 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.
This was exactly the reason for IN_LAZYACCESS flag introduction. It is
set when fs is suspending or suspended, and no IN_CHANGE or IN_UPDATE
flags are set.
> 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.
I think that you statement is valid for both MNTK_SUSPEND and
MNTK_SUSPENDED flags. In other words, aquision of mount interlock could
be safely removed from the ufs_itimes(), as was suggested by ssouhlal@.
Index: ufs/ufs/ufs_vnops.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.283
diff -u -r1.283 ufs_vnops.c
--- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 -0000 1.283
+++ ufs/ufs/ufs_vnops.c 13 Dec 2006 14:10:31 -0000
@@ -133,19 +133,15 @@
{
struct inode *ip;
struct timespec ts;
- int mnt_locked;
=20
ip =3D VTOI(vp);
- mnt_locked =3D 0;
- if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0) {
- VI_LOCK(vp);
+ VI_LOCK(vp);
+ if ((vp->v_mount->mnt_flag & MNT_RDONLY) !=3D 0)
goto out;
+ if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0) {
+ VI_UNLOCK(vp);
+ return;
}
- MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */
- mnt_locked =3D 1;
- VI_LOCK(vp);
- if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) =3D=3D 0)
- goto out_unl;
=20
if ((vp->v_type =3D=3D VBLK || vp->v_type =3D=3D VCHR) && !DOINGSOFTDEP(v=
p))
ip->i_flag |=3D IN_LAZYMOD;
@@ -172,10 +168,7 @@
=20
out:
ip->i_flag &=3D ~(IN_ACCESS | IN_CHANGE | IN_UPDATE);
- out_unl:
VI_UNLOCK(vp);
- if (mnt_locked)
- MNT_IUNLOCK(vp->v_mount);
}
=20
/*
[ It seems that MNTK_SUSPENDED flag implies MNTK_SUSPEND. ]
--DfnuYBTqzt7sVGu3
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFgBC7C3+MBN1Mb4gRAjh5AKCJMQ5r75BZzdBmSsbTsVP4BKwwDQCdGdbU
X7NQQPclVss8dvVKJp6NYQY=
=ZWzx
-----END PGP SIGNATURE-----
--DfnuYBTqzt7sVGu3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061213143955.GM311>