RE: [Bug translator/1276] support more timer varieties

["Stone, Joshua I" <joshua.i.stone@intel.com>]

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