This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Bug translator/1276] support more timer varieties
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 1 Dec 2005 16:38:07 -0500
- Subject: Re: [Bug translator/1276] support more timer varieties
- References: <CBDB88BFD06F7F408399DBCF8776B3DC05C039A8@scsmsx403.amr.corp.intel.com>
Hi -
> [...] timer.profile is always in interrupt, so current->tgid is not
> accessed. I tried this without the in_interrupt check, and the pids
> I got looked fine. [...] The reason you might NOT want to read
> from current in an interrupt is that it may be misleading to the
> user if they're not expecting this.
Is that the only reason? I was under the impression that it is also
possible for utterly fictional "current" values to be left in place,
which could cause problems if dereferenced.
> [...]
> I think the best solution would be if we had some sort of global flag
> that indicated that we're in a profiling interrupt. That way we could
> have something like this:
> function pid:long () %{
> if (unlikely(in_interrupt() && !_stp_in_profiling_interrupt))
> THIS->__retvalue = 0;
> else
> THIS->__retvalue = current->tgid;
> %}
Or a "I believe `current' is safe to dereference here." flag.
I am rather embarrassed to suggest this in the interim:
# if (unlikely(in_interrupt() &&
# strcmp(CONTEXT->probe_point, "timer.profile")))
- FChE