As it turns out, r186347 actually is insufficient to avoid the use of the

curthread-accessing part of mtx_{,un}lock(9) when using a r210623-style
curthread implementation on sparc64, crashing the kernel in its early
cycles as PCPU isn't set up, yet (and can't be set up as OFW is one of the
things we need for that, which leads to a chicken-and-egg problem). What
happens is that due to the fact that the idea of r210623 actually is to
allow the compiler to cache invocations of curthread, it factors out
obtaining curthread needed for both mtx_lock(9) and mtx_unlock(9) to
before the branch based on kobj_mutex_inited when compiling the kernel
without the debugging options. So change kobj_class_compile_static(9)
to just never acquire kobj_mtx, effectively restricting it to its
documented use, and add a kobj_init_static(9) for initializing objects
using a class compiled with the former and that also avoids using mutex(9)
(and malloc(9)). Also assert in both of these functions that they are
used in their intended way only.
While at it, inline kobj_register_method() and kobj_unregister_method()
as there wasn't much point for factoring them out in the first place
and so that a reader of the code has to figure out the locking for
fewer functions missing a KOBJ_ASSERT.
Tested on powerpc{,64} by andreast.

Reviewed by:	nwhitehorn (earlier version), jhb
MFC after:	3 days

2 files changed, 16 insertions, 3 deletions

diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile
index 3026ef8..0870355 100644
--- a/share/man/man9/Makefile
+++ b/share/man/man9/Makefile
@@ -724,7 +724,8 @@ MLINKS+=kobj.9 DEFINE_CLASS.9 \
 	kobj.9 kobj_class_free.9 \
 	kobj.9 kobj_create.9 \
 	kobj.9 kobj_delete.9 \
-	kobj.9 kobj_init.9
+	kobj.9 kobj_init.9 \
+	kobj.9 kobj_init_static.9
 MLINKS+=kproc.9 kproc_create.9 \
 	kproc.9 kproc_exit.9 \
 	kproc.9 kproc_resume.9 \
diff --git a/share/man/man9/kobj.9 b/share/man/man9/kobj.9
index aed1244..0e1745e 100644
--- a/share/man/man9/kobj.9
+++ b/share/man/man9/kobj.9
@@ -28,7 +28,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd April 4, 2000
+.Dd November 14, 2011
 .Dt KOBJ 9
 .Os
 .Sh NAME
@@ -48,6 +48,8 @@
 .Ft void
 .Fn kobj_init "kobj_t obj" "kobj_class_t cls"
 .Ft void
+.Fn kobj_init_static "kobj_t obj" "kobj_class_t cls"
+.Ft void
 .Fn kobj_delete "kobj_t obj" "struct malloc_type *mtype"
 .Fn DEFINE_CLASS name "kobj_method_t *methods" "size_t size"
 .Sh DESCRIPTION
@@ -88,10 +90,14 @@ Objects created in this way should be freed by calling
 Clients which would like to manage the allocation of memory
 themselves should call
 .Fn kobj_init
+or
+.Fn kobj_init_static
 with a pointer to the memory for the object and the class which
 implements it.
 It is also possible to use
 .Fn kobj_init
+and
+.Fn kobj_init_static
 to change the class for an object.
 This should be done with care as the classes must agree on the layout
 of the object.
@@ -109,13 +115,19 @@ A client should not normally need to call these since a class
 will automatically be compiled the first time it is used.
 If a class is to be used before
 .Xr malloc 9
-is initialised,
+and
+.Xr mutex 9
+are initialised,
 then
 .Fn kobj_class_compile_static
 should be called with the class and a pointer to a statically
 allocated
 .Vt kobj_ops
 structure before the class is used to initialise any objects.
+In that case, also
+.Fn kobj_init_static
+should be used instead of
+.Fn kobj_init .
 .Pp
 To define a class, first define a simple array of
 .Vt kobj_method_t .