On Thu, 19 Nov 2015, Jonathan T. Looney wrote:
On 11/19/15, 12:58 PM, "John Baldwin" <[email protected]> wrote:
Note that if you are going to document in each section 9 manpage which
APIs
are not safe to call in a critical section, you will need to update just
about every section 9 manpage. A more prudent approach would probably be
to
instead go the sigaction(2) route and instead document the subset of APIs
which are permissible to call in critical_enter(9). The list is probably
not
very long. Off the top of my head I can think of sched_*, swi_sched,
taskqueue_enqueue_fast, and little else.
Point taken.
Both the man page and the KASSERT()s with redundant (yet incomplete) "or"
clause about spinlocks.
The change also has some style bugs (extra blank lines).
The above list is similar to the list of APIs that may be called by a
"fast" interrupt handler. It is much smaller than the full list, but
still unmanageably large. The closure of the list is difficult to
determined, and the closure of the list of calls actually made is
infinite due to bugs like console drivers calling kdb_alt_break() which
calls everything via reboot() and panic() (also via kdb_enter(), but
the only correct reason for existence of kdb_alt_break() is to enter
kdb, and kdb is a little more careful about not calling everything).
As noted above, the point wasn't to enable checking when WITNESS was
disabled; rather, the point was to make the existing checks more
consistent. Basically, if you do something that engenders a panic at high
scale, you should get consistent behavior at low scale, too.
Checking that is actually done is also likely to cause recursive panics
when panic() is called with in a critical section or in another bad
state. This may be considered as a feature. It limits the damage
when panic() wanders into normal code does unsafe things for the
bad state, and inhibits bugs like kdb_alt_break() calling panic().
Bruce
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "[email protected]"