Date: Sun, 8 May 2005 00:02:51 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Xu <davidxu@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gmon mcount.c Message-ID: <20050507233855.G14804@delplex.bde.org> In-Reply-To: <427C9080.90808@freebsd.org> References: <200505060737.j467b2R4041476@repoman.freebsd.org> <20050507043824.P12302@delplex.bde.org> <427C10D8.9060600@freebsd.org> <20050507183626.Y1839@epsplex.bde.org> <427C9080.90808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 7 May 2005, David Xu wrote: > Bruce Evans wrote: > ... > I know function can be compiled without profiling. I don't think mcount > is to be used to record cpu time, it is only used for recording call graph, > cpu time is recorded by kernel's clock interrupt, if a function is called by > .mcount, its cpu time will be record by kernel, and because mcount is called > everywhere, I guess the final result will show those functions called by > mcount in gprof result, possible solution is inlining syscalls as assmeble > code in mcount. Oops, I forgot that cpu time counting is only done in mcount() for high resolution profiling (GUPROF case). High resolution profiling is still not implemented in userland though userland's mcount.c has parts of it. >> Disabling of scheduling for even system scope threads could probably >> be handled by making a syscall to do it. The syscall would have to >> be compiled without profiling. But this would be very inefficient >> and migh cause security problems (it would let a thread prevent its >> own rescheduling forever). > > I don't think we want to create security risk, userland code can lockup > kernel. The security problem could probably be handled by killing the process if it tries to delay its rescheduling for too long. High priority user processes (realtime and idletime+priority inversion) looping with signals blocked already cause similar security problems -- they don't get rescheduled in the normal way, and you can't kill them even if you have a controlling terminal for them (since they block signal) unless you happen to be running a higher priority process. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050507233855.G14804>