Subject: Re: Adding KASSERT() calls to "sys/sys/queue.h"
To: Matthias Scheler <tron@zhadum.de>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/16/2004 16:09:54
--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 16, 2004 at 08:48:11PM +0000, Matthias Scheler wrote:
> Hello,
>=20
> while I was examining PR kern/25868 I discoverd that a mbuf was freed twi=
ce
> and therefore inserted into a pool twice. I finally found the code causing
> the bug by modifying MFREE() like this:
[snip]
> They will of course not catch all possible errors but they would have
> noticed the problem described above.
>=20
> Opinions?
I think it would be good to have such tests around. I'm not sure if they=20
should be turned on with all the other queue debugging or with a second,=20
additional control. I tend to think the latter, as exactly what error=20
we're looking for can vary from problem to problem; I thought the current=
=20
debug tests were to notice gross queue corruption whereas your check=20
catches incorrect queue use. But it could be that the test is cheep enough=
=20
that the difference doesn't matter.
I am concerned though about the use of a bare KASSERT() though. It is
reasonable to use sys/queue.h macros in userland, which doesn't have a
KASSERT() defined (AFAICT). So a second define to turn on the KASSERT=20
would probably be best.
Take care,
Bill
--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFA0NNCWz+3JHUci9cRAm5KAJ9w5JLz7XaYL/noMRantLwc5WBtQgCgmIES
nLRfq/d9YeIkPS2+bBX1byo=
=Zp5B
-----END PGP SIGNATURE-----
--AhhlLboLdkugWU4S--