probes, interrupt handling, etc

[Frank Ch. Eigler]

Hi -


[moving to systemtap@sourceware]

wcohen wrote:

> [...] It appears that [kprobe_lock] is for accessing the data structure
> that holds the information about which addresses have kprobe int3 set
> and the appropriate handler for them.

That would make sense, over the duration where actual shared
data is being accessed.

> It seems like this could be replaced with multiple reader/one writer 
> locks to allow concurrency in handling the kprobes.

I believe the only reader/writer locking primitives in the kernel
involve semaphores (which can block/sleep), not spinlocks.  Unless
I'm mistaken, this makes them unsuitable for use from within an
interrupt context.

This brings up an interesting issue that relates to lifecycle
management of the probes: specifically setting a good
synchronization policy amongst the asynchronous probe functions
and user-level supervisor startup/suspend/shutdown operations.

I have a little state transition diagram that models a
generalized form of the situation, which (for a small fee
or taunt) I am willing to embarrass myself with by posting.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050203/aef02e4f/attachment.sig>