Subject: Re: Buffers and vnodes
To: Andrew Doran <ad@netbsd.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/25/2007 11:01:23
--GRPZ8SYKNexpdSJ7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 25, 2007 at 02:13:51PM +0100, Andrew Doran wrote:
> Hi,
>=20
> One of the remaining problem areas in vfs wrt locking is the buffer cache.
> With vfs & ffs run without the kernel lock, eventually the system will
> deadlock with one or more threads stuck in in biowait. So I guess that
> somewhere the necessary locks are not being taken, and it's losing state.
>=20
> I've been looking into simplifying the locking, as it's unclear what's
> covered by the long term lock (B_BUSY) and the short term lock
> (b_interlock). One thing I'd like to do is replace b_interlock with a
> pointer to the interlock for the vnode that the buffer is currently
> associated with.
>=20
> That would simplify things, but the catch is that buffers don't have to be
> associated with vnodes. Rather than handle that as a seperate case, would=
 it
> make sense to dictate that buffers must always be associated with a vnode?
> That would also simplify reference counting around character / block
> devices, meaning that we could reliably prevent unloading an LKM device
> that's in use.

Sounds good. I assume buffers that are unassociated now would end up being=
=20
associated with the device node?

Take care,

Bill

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

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

iD8DBQFGgALzWz+3JHUci9cRAhaXAJ4vTvsg+nNu31eEMX8gUcFtufJLugCeKaXc
j692aktfXu2QuKfgFrVMJIE=
=ZKh+
-----END PGP SIGNATURE-----

--GRPZ8SYKNexpdSJ7--