Currently the LO_NOPROFILE flag (which is masked on upper level code by

per-primitive macros like MTX_NOPROFILE, SX_NOPROFILE or RW_NOPROFILE) is
not really honoured. In particular lock_profile_obtain_lock_failure() and
lock_profile_obtain_lock_success() are naked respect this flag.
The bug leads to locks marked with no-profiling to be profiled as well.
In the case of the clock_lock, used by the timer i8254 this leads to
unpredictable behaviour both on amd64 and ia32 (double faults panic,
sudden reboots, etc.). The amd64 clock_lock is also not marked as
not profilable as it should be.
Fix these bugs adding proper checks in the lock profiling code and at
clock_lock initialization time.

i8254 bug pointed out by: kris
Tested by: matteo, Giuseppe Cocomazzi <sbudella at libero dot it>
Approved by: jeff (mentor)
Approved by: re

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/kern/subr_lock.c b/sys/kern/subr_lock.c
index f20f80e..33e2bdd 100644
--- a/sys/kern/subr_lock.c
+++ b/sys/kern/subr_lock.c
@@ -274,7 +274,7 @@ void _lock_profile_release_lock(struct lock_object *lo)
 {
         struct lock_profile_object *l = &lo->lo_profile_obj;
 
-        if (l->lpo_acqtime && !(lo->lo_flags & LO_NOPROFILE)) {
+        if (l->lpo_acqtime) {
                 const char *unknown = "(unknown)";
                 u_int64_t acqtime, now, waittime;
                 struct lock_prof *mpp;