Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Aug 2006 16:44:21 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Eric Anderson <anderson@centtech.com>
Cc:        freebsd-fs@freebsd.org, tegge@freebsd.org
Subject:   Re: Deadlock between nfsd and snapshots.
Message-ID:  <20060821134421.GC56637@deviant.kiev.zoral.com.ua>
In-Reply-To: <44E9B722.2040407@centtech.com>
References:  <20060817170314.GA17490@peter.osted.lan> <20060818164903.GF20768@deviant.kiev.zoral.com.ua> <20060818.202001.74745664.Tor.Egge@cvsup.no.freebsd.org> <20060821.132151.41668008.Tor.Egge@cvsup.no.freebsd.org> <44E9B722.2040407@centtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--WplhKdTI2c8ulnbP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 21, 2006 at 08:37:38AM -0500, Eric Anderson wrote:
> On 08/21/06 08:21, Tor Egge wrote:
> >I wrote:
> >
> >>The deadlock indicates that one or more of IN_CHANGE, IN_MODIFIED or
> >>IN_UPDATE was set on the inode, indicating a write operation
> >>(e.g. VOP_WRITE(), VOP_RENAME(), VOP_CREATE(), VOP_REMOVE(), VOP_LINK(),
> >>VOP_SYMLINK(), VOP_SETATTR(), VOP_MKDIR(), VOP_RMDIR(), VOP_MKNOD()) th=
at=20
> >>was
> >>not protected by vn_start_write() or vn_start_secondary_write().
> >
> >The most common "write" operation was probably VOP_GETATTR().
> >
> >ufs_itimes(), called from ufs_getattr(), might set the IN_MODIFIED inode=
=20
> >flag
> >if IN_ACCESS is set on the inode even if neither IN_CHANGE nor IN_UPDATE=
 is
> >set, transitioning the inode flags into a state where ufs_inactive() cal=
ls=20
> >the
> >blocking variant of vn_start_secondary_write().
> >
> >calling ufs_itimes() with only a shared vnode lock might cause unsafe=20
> >accesses
> >to the inode flags.  Setting of IN_ACCESS at the end of ffs_read() and
> >ffs_extread() might also be unsafe.  If DIRECTIO is enabled then O_DIREC=
T=20
> >reads
> >might not even attempt to set the IN_ACCESS flag.
>=20
> Does this mean that setting the noatime flag on mount would dodge this?
On the server, yes.

--WplhKdTI2c8ulnbP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE6bi1C3+MBN1Mb4gRAi0AAKCAMHYgGLM2NiwbeACHYWYcf7KGBACdHaFr
bsTADBtxT8QDEPAA9iT0YT0=
=ic3w
-----END PGP SIGNATURE-----

--WplhKdTI2c8ulnbP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060821134421.GC56637>