[Bug runtime/9947] New: lockdep triggered on rawhide with tracepoints

[Bug runtime/9947] New: lockdep triggered on rawhide with tracepoints

[jistone at redhat dot com]

When running a simple tracepoint test (below), I noticed a lockdep report of a
circular dependency.  This is just potential problem though, as I haven't had
any deadlocks actually manifest.

The report I'm attaching is for i686, but I also reproduced this on x86_64.

# test script:
probe kernel.trace("sched_switch") { exit() }

-- 
           Summary: lockdep triggered on rawhide with tracepoints
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jistone at redhat dot com


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

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

[Bug runtime/9947] lockdep triggered on rawhide with tracepoints

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-12 19:06 -------
Created an attachment (id=3816)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3816&action=view)
lockdep report


-- 


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

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

[Bug runtime/9947] lockdep triggered on rawhide with tracepoints

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-13 00:41 -------
The scenario to make this actually deadlock seems to be pretty pathological.  We
would have to be unregistering a tracepoint from the work queue at the same time
as cleanup_module is trying to destroy the work queue.  We only run the work
queue while there's a transport channel attached though, which means the module
refcnt is non-zero, so the only way to also be in cleanup_module is with a
*forced* rmmod.  Even the rmmod manpage says that forcing is extremely
dangerous, so I wouldn't apologize too much if we locked up in that scenario.

-- 


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

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

[Bug runtime/9947] lockdep triggered on rawhide with tracepoints

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-13 00:48 -------
Created an attachment (id=3819)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3819&action=view)
Possible fix to get rid of lockdep warning

Still, it's better that we don't spew lockdep warnings into the logs, no matter
how unlikely the actual deadlock.

This adds STP_REQUEST_EXIT that the work queue can send, instead of directly
unregistering probes.  User mode will send up STP_EXIT then, at which point the
actual unregistering and cleanup can occur.

This does eliminate the lockdep message for me, but it will add more delay
between a script exit() and actually disarming the probes...

-- 


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

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

[Bug runtime/9947] lockdep triggered on rawhide with tracepoints

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-13 21:37 -------
(In reply to comment #3)
> Created an attachment (id=3819)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3819&action=view)
> Possible fix to get rid of lockdep warning

committed as 52aeb26b8d83c26e00adaf70bbf5a3a828689fb2.

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


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

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