On Mon, Apr 11, 2005 at 10:59:10PM -0700, Vara Prasad wrote:
Maneesh Soni wrote:
On Tue, Apr 12, 2005 at 09:26:50AM +0530, Suparna Bhattacharya wrote:
It would be nice to summarize all the requirements upfront, before
moving on to the design.
I had the impression that systemTap needs that register_kprobe() should
never fail with -EEXIST. That means, if there is a kprobe inserted by some
other utility at the same location where systemTap wants to insert, the
kprobe
mechanism should still go ahead and add handlers to the existing kprobe.
That is right, we should allow multiple handlers at any given probe point.
Thanks to Suparna, I see there could be a problem in this which might
occur due to this non-exclusiveness of kprobes. Consider the following
scenario,
utility 1 inserts kprobe k1 with handler h1 at address A
utility 2 wants to insert kprobe k2 with handler h2 at the same address A
In this situation if we do _not_ fail user 2 and add handler h2 to the
existing
kprobe, what might happen is that if at the hit of kprobe, the handler h1
can modify some data and things might not be as expected by h2. The result
could be the incorrect information being provided by utility 2.
When we have multiple handlers we are not guaranteeing the order of
execution of probes hence probe handlers should not assume any order.
Handlers should have the logic to verify the data of their interest
before using, if data is not appropriate they should handle that
gracefully and exit.
I understand that systemTap needs multiple handler probes, but still there
should be some exclusiveness among the kprobes inserted by different
utilities.
One utility can synchronize its own multiple handlers for the same probe
but
with other utilities.
I think synchronization should be left to the users of the probes rather
than trying to complicate the interface with exclusive probes and non
exclusive probes.
Indeed. That is exactly the point -- we can impose the requirement of
verification on systemtap probes or multihandler probes in general,
but changing all kprobes users to do this may not be appropriate.
Simply keeping the same name of the interface and changing its semantics is
potentially problematic.
kprobes is a simple low level interface - the only expectation on
kprobes handlers today is ability to execute in interrupt context
and not recurse into itself. Other than that, a handler is a kernel
function - which can do whatever it wants ... it would be rather hard
if not impossible to verify everything.
So, I can't see a way to make unrelated sets of users of probes
to synchronize themselves :(