Bug 14409 - Delay inode-uprobes registration until after buildid checks
Summary: Delay inode-uprobes registration until after buildid checks
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: David Smith
Depends on:
Reported: 2012-07-26 17:52 UTC by Josh Stone
Modified: 2012-08-02 15:47 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Josh Stone 2012-07-26 17:52:44 UTC
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.
Comment 1 David Smith 2012-08-02 15:47:07 UTC
Fixed in commit 509b6dd.