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]

Re: [RFC] Multiple kprobes at an address redux (take3)


Maneesh Soni wrote:

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.




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.




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.

May be it will become clear if you give a practical example of data or state changes you are talking that can compromise the system stability.

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.


Kprobe being quite low level mechanism, the interfaces it provides should
be designed very carefully so that its users do not misbehave


I think again if you give a more concrete example it will be helpful to understand your point.

Thanks
Maneesh






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]