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: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>, <systemtap at sources dot redhat dot com>
- Date: Thu, 1 Dec 2005 18:54:24 -0800
- Subject: RE: [Bug translator/1276] support more timer varieties
Frank Ch. Eigler wrote:
> 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.
AFAIK, current is always valid. I know in the Vtune driver we
frequently use current during PMU interrupts, and there's never been an
issue. Not to say that Vtune is difinitive - I scanned the kernel
sources as well, and didn't see anything making checks before accessing
current. I also didn't find anything through Google. So unless someone
knows otherwise, or has a reference to cast doubt on this, I think it's
safe.
The "let's not mislead the user" issue may be minor enough that we just
say who cares...
> Or a "I believe `current' is safe to dereference here." flag.
If we determine that there are specific unsafe instances of current,
then yes, this would be nice.
> I am rather embarrassed to suggest this in the interim:
>
> # if (unlikely(in_interrupt() &&
> # strcmp(CONTEXT->probe_point, "timer.profile")))
Hmm... I think we can at least do:
# if (unlikely(in_interrupt() &&
# (CONTEXT->probe_point != "timer.profile")))
Since they are both literal strings, string-pooling should make them
identical pointers. We could whitelist probes this way, but... yuck...
I hope we can get a better answer to the validity of "current".
Josh