This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, Apr 11, 2005 at 10:59:10PM -0700, Vara Prasad wrote:Like i said if there is no guarantee in the order of execution of handlers, a handler can not have assumptions built into it that it can not verify. Remember there will be some handlers that will get fired asynchronous to the execution based on an external event like timer, handlers should be able to cope with those where there is no guarantee of any state due to its asynchronous nature.
Maneesh Soni wrote:
On Tue, Apr 12, 2005 at 09:26:50AM +0530, Suparna Bhattacharya wrote:That is right, we should allow multiple handlers at any given probe point.
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 kprobeIt would be nice to summarize all the requirements upfront, before moving on to the design.
mechanism should still go ahead and add handlers to the existing kprobe.
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,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.
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.
It is not just the question of verifying the data of interest. The changed scenarios for subsequent handlers may cause their assumptions to fail and being in kernel mode they can in turn cause system failures.
I think again if you give a more concrete example it will be helpful to understand your point.I understand that systemTap needs multiple handler probes, but still there should be some exclusiveness among the kprobes inserted by different 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.
One utility can synchronize its own multiple handlers for the same probe but
with other utilities.
Kprobe being quite low level mechanism, the interfaces it provides should
be designed very carefully so that its users do not misbehave
Thanks Maneesh
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |