Date: Wed, 11 Jul 2001 15:04:43 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: tanimura@r.dl.itc.u-tokyo.ac.jp Cc: bright@sneakerz.org, jake@FreeBSD.org, jhb@FreeBSD.org, current@FreeBSD.org Subject: Re: Lock of struct filedesc, file, pgrp, session and sigio Message-ID: <200107110607.f6B64ht61439@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Wed, 11 Jul 2001 10:44:21 %2B0900" <200107110144.f6B1iL080250@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <20010531124007.B57907@dragon.nuxi.com> <XFMail.010531125426.jhb@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2001 10:44:21 +0900, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 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. -- 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?200107110607.f6B64ht61439>