Searched hist:227537 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-11-stable/sys/kern/ | ||
| H A D | subr_kobj.c | diff 227537 Tue Nov 15 18:14:41 MST 2011 marius 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 |
| /freebsd-11-stable/sys/sys/ | ||
| H A D | kobj.h | diff 227537 Tue Nov 15 18:14:41 MST 2011 marius 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 |
| /freebsd-11-stable/sys/dev/ofw/ | ||
| H A D | openfirm.c | diff 227537 Tue Nov 15 18:14:41 MST 2011 marius 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 |
| /freebsd-11-stable/sys/powerpc/powerpc/ | ||
| H A D | pmap_dispatch.c | diff 227537 Tue Nov 15 18:14:41 MST 2011 marius 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 |
Completed in 216 milliseconds