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

On Fri, Jun 23, 2006 at 09:02:33PM +0200, Juergen Hannken-Illjes wrote:
> On Fri, Jun 23, 2006 at 10:26:00AM -0700, Bill Studenmund wrote:
> > On Thu, Jun 22, 2006 at 05:55:52PM +0200, Juergen Hannken-Illjes wrote:
> > > For specfs/fifofs we could
> > >=20
> > >     need_hold =3D (vp->v_flags & VHOLD);
> > >     if (need_hold)
> > > 	vn_release(vp);
> > >     ... device operation that may sleep long ...
> > >     if (need_hold)
> > > 	vn_hold(vp, V_WAIT);
> >=20
> > I don't see why fifofs should get special treatment.
>=20
> It has long sleeps on "fifor" and "fifow" and its so_receive() and so_sen=
d()
> calls may also go to long sleep.

The thing is that if we are really trying to support transactions, the
it's very questionable for the file system to release then reaquire the=20
transaction lock.

Especially if we go with the idea of having the file system grab and=20
release the mountpoint-transaction-lock (the current incarnation of the=20
"gate" you spoke of originally, the thing that makes us atomic w.r.t. a=20
snapshot), then it's not a problem. We just have the read and write code=20
in fifofs not take the transaction lock, and we're fine.

Not taking a lock is fine, releasing someone else's lock and retaking one=
=20
is a problem.

Such a change would limit our exposure to cases where someone is trying to=
=20
make a transaction that involves writing to or reading from a fifo. If you=
=20
try to do that, you get what you get.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEnIPIWz+3JHUci9cRAnBHAJ9lgTpIh+QcVpck+Mx1KChhhwLSrwCdHDRz
XiWfIFK2i746XCW4fhvoV3Y=
=CfQy
-----END PGP SIGNATURE-----

--tMbDGjvJuJijemkf--