From owner-freebsd-current Wed Jul 11 4:24:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 883CD37B40B; Wed, 11 Jul 2001 04:24:21 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f6BBOHt20234 ; Wed, 11 Jul 2001 20:24:18 +0900 (JST) Message-Id: <200107111124.f6BBOHt20234@rina.r.dl.itc.u-tokyo.ac.jp> Date: Wed, 11 Jul 2001 20:24:17 +0900 From: Seigo Tanimura 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 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> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 11 Jul 2001 01:44:55 -0500, Alfred Perlstein 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message