Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Dec 1997 03:36:05 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        henrich@crh.cl.msu.edu (Charles Henrich)
Cc:        perhaps@yes.no, freebsd-current@freebsd.org
Subject:   Re: VM system info
Message-ID:  <199712100336.UAA06192@usr06.primenet.com>
In-Reply-To: <199712091643.LAA04851@crh.cl.msu.edu> from "Charles Henrich" at Dec 9, 97 11:43:31 am

next in thread | previous in thread | raw e-mail | index | archive | help
> >(5) Code prerequisites is documented through assert() or similar
> >    functionality.
> 
> Egads!  I wish assert() was thrown down to the pits of hell.  Its a
> programmers cop out.  In almost no circumstance does one ever need to assert.
> If you find an error condition, COPE as best you can!  Especially in the
> kernel.

The function of an assert() is not to live in production code.

The function of assert() is to provide developers with feedback about
improper use of function interfaces.

This lets functions document expectations on the way in, and, if you
correctly implement single-entry/single-exit like you should, on the
way out as well.

A good example would be functions with locking side-effects.  Like those
involved in causeing the "free vnode isn't" bug we are all so fond of,
but for which the code is a sacred cow and so it's never been fixed.

Knowing that a lock that was supposed to be held is not held as expected,
or is held when it is not expected to be held, in combination with a
branch-patch validation to exercise all code paths can result in early
and easy identification and correction of bugs.

Right now, there is an obvious error in VOP_LOCK()'s interaction with
vclean() and associated functions (for example), resulting in the
"free vnode isn't" bug described above.

This is only going to get worse in the SMP kernel, and in the UP kernel,
assuming we allow for kernel preemption for use in supporting things like
kernel threads and kernel processes.  So it's not an SMP only problem.

Topologically, other than the names for the primitives, Kernel preemption
for RT support is equivalent to kernel preemption for kernel threading
support is equivalent to kernel reeentrancy for SMP.

I can't see SMP progressing to discrete locking with any reasonable
guarantess against deadlock or inversion bugs without this type of
assurance.

In production code, and assert becomes a comment, and is not even compiled
into the code.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



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