Re: probes, interrupt handling, etc

["Frank Ch. Eigler" <fche at redhat dot com>]

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

Attachment: pgp00000.pgp
Description: PGP signature