Subject: Re: Buffers and vnodes
To: None <tech-kern@netbsd.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/26/2007 18:13:28
--dTy3Mrz/UPE2dbVg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 25, 2007 at 08:39:25PM +0200, Joerg Sonnenberger wrote:
> On Mon, Jun 25, 2007 at 11:30:16AM -0700, Bill Stouder-Studenmund wrote:
> > On Mon, Jun 25, 2007 at 08:06:37PM +0200, Joerg Sonnenberger wrote:
> > > Is it really a good idea to make the vnode locking even more
> > > complicated?
> >=20
> > Are you sure this will make vnode locking more complicated?
>=20
> Well. We add a dependency of a subsystem that was currently not caring
> about vnodes to the vnode locking. So far it sounds like a regression.
> The real question for me is whether the access to a buf is hierachical
> relative to a possible associated vnode or not.

I'd been meaning to comment, and Andrew's comment spurred me on.

I'm not really sure that bufs didn't care about vnodes. While drivers=20
don't care much about the vnode owning a buf, I think there's almost=20
always a vnode around (or another driver like cgd, but even it has a=20
vnode) for all the other cases. And that vnode either cares or can be a=20
proxy (say for cgd) for something that cares about the buff.

> In other words: if I have a buf and the associated vnode, can I get in
> situation where I want to lock either the buf or the vnode and have the
> other data structure locked independently? If not, they shouldn't be
> related. If the answer is yes, does the buf lock depend on the vnode
> being locked? Do we have callbacks that could trigger recursion? If not,
> it would be nice to keep the buf locking as relative leaf. Otherwise the
> question remains whether we can change it to have such a hierachy :-)

Good question. I think the answer is no, but it's good to ask.

Take care,

Bill

--dTy3Mrz/UPE2dbVg
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGgbm4Wz+3JHUci9cRAnpEAJ4vcePbivND8g84dmdwFl9eacD+/ACeLrwN
46yT6WNuFSJFDiODLtxYBvs=
=9Jlg
-----END PGP SIGNATURE-----

--dTy3Mrz/UPE2dbVg--