From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 14:40:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73E016A407; Wed, 13 Dec 2006 14:40:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A515D43CB5; Wed, 13 Dec 2006 14:38:47 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1GuVHB-000FEe-1o; Wed, 13 Dec 2006 16:40:13 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBDEdxBZ011609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 16:39:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kBDEdxmt003633; Wed, 13 Dec 2006 16:39:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBDEdtJu003632; Wed, 13 Dec 2006 16:39:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Dec 2006 16:39:55 +0200 From: Kostik Belousov To: Tor Egge Message-ID: <20061213143955.GM311@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> <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DfnuYBTqzt7sVGu3" Content-Disposition: inline In-Reply-To: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua X-Scanner-Signature: c743d2f542030c7d5376417eb66b5b31 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 602 [Dec 13 2006] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-Mailman-Approved-At: Wed, 13 Dec 2006 15:46:28 +0000 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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 14:40:20 -0000 --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--