anything that just causes the function to die on that bug reliably
during normal use, without having to enable DEBUG_KOBJECT which just
kills the system due to its verbosity. A magic value would be perfect.
Are kobjects protected against accidental copying? If not add &kobj to
the 'magic value' too, and check that - it becomes copying-resistent
that way and has the same cost to check. (which is negligible anyway)
no argument about that at all! This is exactly the same problem that the
spinlock/mutex/rwlock/etc. APIs were facing: it's used everywhere, and
that means dubious places as well that are not that well-known and are
rarely used. The more widely used a piece of kernel infrastructure is,
the more 'hardened' it must be against intentional or accidental abuse.
(at least with certain magic debug options enabled)
So please regard this a good thing - obscure APIs need no debugging
infrastructure - widely used ones do need quite extensive debugging
infrastructure.
For example locks currently have 4000 lines of code of debugging
infrastructure and 1500 lines of code of self-tests. The total amount of
core locking code is less 1000 lines of code. So for every line of
locking code there's more than 5 lines of debugging infrastructure (!).
And we only print to the console if we think there is a bug. That
extensive infrastructure is _good_, because locks are so central to all
our data structures that catching bugs as soon as possible (in fact
sooner than they trigger) aids in keeping bad code out of the kernel
ASAP.
Ingo
--
