Date: Wed, 11 Jul 2001 20:24:17 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: bright@sneakerz.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, jake@FreeBSD.org, jhb@FreeBSD.org, current@FreeBSD.org Subject: Re: Lock of struct filedesc, file, pgrp, session and sigio Message-ID: <200107111124.f6BBOHt20234@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Wed, 11 Jul 2001 01:44:55 -0500" <20010711014455.H1894@sneakerz.org> References: <20010531130155.A58258@dragon.nuxi.com> <200106011228.f51CSvD46848@rina.r.dl.itc.u-tokyo.ac.jp> <20010602125223.J31257@dragon.nuxi.com> <200106040748.f547mUD53783@rina.r.dl.itc.u-tokyo.ac.jp> <200106181004.f5IA4VD63112@rina.r.dl.itc.u-tokyo.ac.jp> <200107020812.f628CfK44241@rina.r.dl.itc.u-tokyo.ac.jp> <20010707164249.C88962@sneakerz.org> <20010709032044.B1894@sneakerz.org> <200107110144.f6B1iL080250@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200107110607.f6B64ht61439@rina.r.dl.itc.u-tokyo.ac.jp> <20010711014455.H1894@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2001 01:44:55 -0500, Alfred Perlstein <bright@sneakerz.org> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107111124.f6BBOHt20234>