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: probes, interrupt handling, etc


Frank Ch. Eigler wrote:
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.

There are read/write spinlocks to improve concurrency. You can see them used in the ext2 file system and a number of device drivers. The read/write spinlocks are defined in spinlock.h. For example:


#ifdef CONFIG_SMP
#define spin_lock_irqsave(lock, flags)	flags = _spin_lock_irqsave(lock)
#define read_lock_irqsave(lock, flags)	flags = _read_lock_irqsave(lock)
#define write_lock_irqsave(lock, flags)	flags = _write_lock_irqsave(lock)
#else
#define spin_lock_irqsave(lock, flags)	_spin_lock_irqsave(lock, flags)
#define read_lock_irqsave(lock, flags)	_read_lock_irqsave(lock, flags)
#define write_lock_irqsave(lock, flags)	_write_lock_irqsave(lock, flags)
#endif

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.

However, you are right there are still the asynchronous startup/suspend/shutdown operation issues.


I have to taut you to get you to post the state transition diagram? What was used to draw it? PowerPoint?

--Will


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