Re: [TAPSETS] Linux Kernel Event Trace Tool

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> 
> Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> 
> Not exactly.  Those functions could still in theory be instrumented,
> but an actual run-time reentry into the probing system would be
> detected, the probe short-circuited, and a "missed probe" would be
> recorded.
> 
> > Page faults and NMI handlers are two examples where this locking
> > scheme fails.  All traps, exceptions and fault handlers cannot then
> > be safely instrumented,
> 
> I am probably missing something.  Could you sketch out a scenario that
> causes a safety problem?
>

Sure,


Let's think someone is probing a device which uses an NMI watchdog, and is
interested to see if each event is really delivered to the CPU. In that
scenario, if the tracer discards one event, then the user would have to restart
the tracing.

Now, let's think that the NMI is not the only asynchronous source of
non-maskable interrupts : spurious interrupts could be another example or page
faults (internal source though).

If the person is interested into tracing the whole system (process events,
softirqs, interrupts and NMI) to see the root of a problem, then a "event lost"
will happen as soon as an NMI tries to reenter into the logging code. That will
leave an incomplete trace.

The cleanest way I found to log NMIs without losing event is to make the
logging code reentrant by itself by using atomic operations.

Mathieu



OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68