[Bug runtime/11154] New: -DDEBUG_REENTRANCY needs robust reporting

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

On a kernel.trace("*") script, often there are reentrant probes
due to the nature of the low level kernel facilities being used
by systemtap itself.  However, actually listing these reentrancy
events with -DDEBUG_REENTRANCY is not sufficiently robust, as it
seems that the diagnostics code itself can induce further reentrancy.
Oops.

tapsets.cxx (common_probe_entryfn_prologue):
  o->newline() << "#ifdef STP_TIMING";
  o->newline() << "atomic_inc (& skipped_count_reentrant);";
  o->newline() << "#ifdef DEBUG_REENTRANCY";
  o->newline() << "_stp_warn (\"Skipped %s due to %s residency on cpu %u\\n\", "
               << new_pp << ", c->probe_point ?: \"?\", smp_processor_id());";

  [...]
  o->newline() << "#endif";
  o->newline() << "#endif";

If _stp_warn invokes anything that can cause further tracepoints,
such as spinlock operations, we're sunk.
"BUG: spinlock recursion on..." <hang>

So instead of a direct stp_warn, let's track conflicting-pp() tuples
in some little array (locklessly), then report on them at the end
of the run.

Or -DSTAP_DEBUG_PRINTK?  On one run I get at least:

[  136.280538] WARNING: Skipped kernel.trace("lock_acquire") due to
kernel.trace("kmem_cache_alloc") residency on cpu 0
[  136.280782] ERROR: Skipped too many probes, check MAXSKIPPED or try again
with stap -t for more details.

-- 
           Summary: -DDEBUG_REENTRANCY needs robust reporting
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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

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