On Wed, 11 Jul 2001 01:44:55 -0500,
Alfred Perlstein <[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().
>>
>> 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
>> ktrcsw().
>>
>> 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
>> ktrace.
Alfred> Yes, it's pretty gross. :(
A problem of checking the cache upon release of a mutex is that we do
not record the mutexes a process holds, which sounds expensive.
BSD/OS solves that problem by a queue of ktrace data, which is what we
refer to as cache, and by a helper kernel thread.
A ktrace queue of BSD/OS, namely struct ktrace_control, is per vnode
of a trace file, allocated dynamically. A record of trace data, also
dynamically allocated, attaches to the queue of a trace file first. A
kernel thread forked in ktrace(2) pulls records out of the queue,
followed by writing them to the vnode of the trace file.
The queue also holds free records of ktrace data so that a process
holding mutexes can call ktrace_*(),
The solution of BSD/OS looks promising in general. The only one issue
I notice is that they do not allocate free records until the first
call of ktrace_getxheader(). That would be fatal if a process holding
mutexes records the first trace data for the queue.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
