On Wed, 11 Jul 2001 10:44:21 +0900,
  Seigo Tanimura <[EMAIL PROTECTED]> said:

Alfred> I'm also quite sure that you can't call the ktrace functions with
Alfred> any mutexes held so the code is doing to need some help, basically
Alfred> the trick in trapsig() and postsig() is to generate the ktrace
Alfred> IO after the locks have been dropped, this means somehow caching
Alfred> the info sent to ktrace where it's currently called, and calling
Alfred> it later with the cached info after the locks are dropped.

Seigo> We can cache ktrace information into struct proc and mark the
Seigo> existence of cache in p_traceflag. Then we send the information to
Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). 

The problem has turned out to be even worse.

msleep() and cv_*wait*() might receive a mutex held by curproc. As we
cannot release the mutex to sleep in ktrwrite() during msleep() or
cv_*wait*(), it is also necessary to cache information sent to

Is it not feasible to examine the existence of cached ktrcsw()
information upon every single call of msleep() and cv_*wait*() in
order to flush the cached information. Instead of that, we should
watch for release of mutexes. When a process no longer holds any
mutexes except for Giant, it is safe to flush cached information to


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to