[Bug uprobes/9828] A uprobe probepoint hit may result in a lockdep warning message

["srikar at linux dot vnet dot ibm dot com" <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.