public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug runtime/14409] New: Delay inode-uprobes registration until after buildid checks
@ 2012-07-26 17:53 jistone at redhat dot com
  2012-07-27 17:49 ` [Bug runtime/14409] " dsmith at redhat dot com
  0 siblings, 1 reply; 2+ messages in thread
From: jistone at redhat dot com @ 2012-07-26 17:53 UTC (permalink / raw)
  To: systemtap

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

             Bug #: 14409
           Summary: Delay inode-uprobes registration until after buildid
                    checks
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap@sourceware.org
        ReportedBy: jistone@redhat.com
    Classification: Unclassified


The old utrace-uprobes operated on a per-process model.  We would use
task_finder to locate processes with the interesting module, then after
verifying the buildid, register a uprobe in that process.

The new inode-uprobes operates on an inode model, systemwide.  I argued that it
doesn't make sense to force the per-process model on this, because you can't
really register a uprobe for just one process.  So instead we're looking up and
registering on inodes when stap.ko starts.  But the downside is that the
buildid check doesn't have any chance to validate this, since the inode may not
even be in memory yet.

So here's a proposed compromise -- delay registration, but still treat it as
systemwide.  This may look roughly like:
(1) On stap.ko start, just register task_finder for each stapiu_target.
(2) The first time a target is seen, check its buildid.  If it matches, then
igrab that inode and register every stapiu_consumer for that target.
(3) Every time the target is seen, still need to manipulate any semaphores.
(4) On stap.ko unload, unregister whatever consumers came alive, and iput all
the targets we did igrab.

Note we don't need to unregister+iput targets when individual processes go
away, because the registration is systemwide, and we know that we have an
inode* with a good buildid.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug runtime/14409] Delay inode-uprobes registration until after buildid checks
  2012-07-26 17:53 [Bug runtime/14409] New: Delay inode-uprobes registration until after buildid checks jistone at redhat dot com
@ 2012-07-27 17:49 ` dsmith at redhat dot com
  0 siblings, 0 replies; 2+ messages in thread
From: dsmith at redhat dot com @ 2012-07-27 17:49 UTC (permalink / raw)
  To: systemtap

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |dsmith at redhat dot com
         AssignedTo|systemtap at sourceware dot |dsmith at redhat dot com
                   |org                         |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-07-27 17:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-26 17:53 [Bug runtime/14409] New: Delay inode-uprobes registration until after buildid checks jistone at redhat dot com
2012-07-27 17:49 ` [Bug runtime/14409] " dsmith at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).