From owner-freebsd-stable@FreeBSD.ORG Wed Dec 13 04:13:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7CA116A403; Wed, 13 Dec 2006 04:13:52 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F7543C9F; Wed, 13 Dec 2006 04:12:25 +0000 (GMT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.13.6/8.13.1) with ESMTP id kBD4DnuW021699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Dec 2006 05:13:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.13.4/8.13.4) with ESMTP id kBD4Dljh077282; Wed, 13 Dec 2006 04:13:47 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Wed, 13 Dec 2006 04:12:57 +0000 (UTC) Message-Id: <20061213.041257.74683466.Tor.Egge@cvsup.no.freebsd.org> To: kostikbel@gmail.com From: Tor Egge 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> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds 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-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 04:13:53 -0000 > 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