This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug uprobes/9828] A uprobe probepoint hit may result in a lockdep warning message
- From: "srikar at linux dot vnet dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 9 Feb 2009 10:49:56 -0000
- Subject: [Bug uprobes/9828] A uprobe probepoint hit may result in a lockdep warning message
- References: <20090209102948.9828.srikar@linux.vnet.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From srikar at linux dot vnet dot ibm dot com 2009-02-09 10:49 -------
Update from Jim Keniston:
-------------------------
Uprobes does indeed hold these semaphores read-locked while single-stepping
an instruction out-of-line:
1. uproc->rwsem -- prevents changes to the uprobe-process's data structures.
2. ppt->slot->rwsem -- prevents the SSOL slot from being stolen while it's
in use.
Uprobes has been doing that for ~2 years. The lockdep_sys_exit() check
was added to Linux maybe a year ago.
The BUG doesn't indicate a problem per se. Either the single-step
operation will complete successfully, or the task will die. In either
case, uprobes will unlock the semaphores. However, when the LOCKDEP
code reports such a problem, it then disables itself; so other,
potentially more serious problems are not reported.
As for #1 above, it's theoretically possible to unlock uproc->rwsem
just before kicking off the single-step operation. In PR #5509,
"uprobes booster thoughts," see the section that starts with "What
happens if the probepoint is unregistered while one or more threads
are executing the instructions in the SSOL slot?"
#2 is perhaps more problematic. Something similar can be achieved by
(essentially faking up a rwsem) using a reference count and a wait queue.
But that's just circumventing the LOCKDEP check. Another possibility
is to somehow ensure that the number of SSOL slots for each process
exceeds the number of threads; that way there's always
at least one slot not currently in use, and the slot seeker would
never have to wait.
One other way you can get a LOCKDEP BUG report
with uprobes is when uprobe_fork_uproc() calls uprobe_mk_process()
for the child (thus creating and locking the child's rwsem) while holding
the parent's rwsem. LOCKDEP doesn't like this. This report could be
suppressed by assigning a different class/level
to the child's rwsem.
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|systemtap at sources dot |srikar at linux dot vnet dot
|redhat dot com |ibm dot com
Status|NEW |ASSIGNED
http://sourceware.org/bugzilla/show_bug.cgi?id=9828
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.