[Bug translator/9930] New: produce more information about probe reentrancy

[Bug translator/9930] New: produce more information about probe reentrancy

[fche at redhat dot com]

With tracepoints, it's easy to generate unintentionally reentrant probes.

# stap -t -e 'probe trace("*") {}' -w

running for a while produces 

WARNING: Number of errors:, skipped probes: NNN
WARNING: Skipped due to reentrancy: NNN

It would be nice to track which probes are reentrant with respect to which
others.  The results may be very intuitive (tracepoints associated with
hardware interrupts), in which case we may need to relax the MAXSKIPPED/etc.
logic for reentrancy, so that such a common case is not penalized.

-- 
           Summary: produce more information about probe reentrancy
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=9930

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9930] produce more information about probe reentrancy

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-03-07 22:12 -------
commit c12d974 helps:  "stap -t -DDEBUG_REENTRANCY ...."

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=9930

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9930] produce more information about probe reentrancy

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-07 23:19 -------
Wouldn't we avoid most of this trouble by running probe handlers with interrupts
disabled?  I know we changed this for #6899, but here we have an example of how
that change can be painful...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9930

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9930] produce more information about probe reentrancy

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-03-07 23:57 -------
> Wouldn't we avoid most of this trouble by running probe handlers with interrupts
> disabled?

Some, but not all.

> I know we changed this for #6899, but here we have an example of how
> that change can be painful...

Reentrance can occur in other ways too - from probed code reached
from an NMI or from the runtime.  So we still have to protect against
it.

We could make it more configurable -- to let a sysadmin/script writer
state a preference between the status quo vs. blocked interrupts and
associated greater latency, in order to have fewer skipped probes.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9930

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9930] produce more information about probe reentrancy

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-08 00:24 -------
(In reply to comment #3)
> Reentrance can occur in other ways too - from probed code reached
> from an NMI or from the runtime.  So we still have to protect against
> it.

Agreed, we will always have those cases.  We can make it better for probing
maskable interrupts though.

> We could make it more configurable -- to let a sysadmin/script writer
> state a preference between the status quo vs. blocked interrupts and
> associated greater latency, in order to have fewer skipped probes.

I like this suggestion.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9930

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.