[RFC] Design + prototype: Multiple kprobes at an address - take 2

[Frank Ch. Eigler]

Hi -


On Fri, Apr 08, 2005 at 07:18:38PM +0530, Prasanna S Panchamukhi wrote:
> [...]
> > [...]
> > I actually still haven't seen a useful thing that custom a fault
> > handler could do for the second case.  Is there some known kprobing
> > scenario where single-stepping faults are dealt with usefully *by* the
> > custom handler (and not the generic unconditional kprobes code)?

> We need to find some real life scenario where single-stepping faults
> and allow the custom handler to deal with it. Later user can use
> these standard custom handler to handle them.

Yes, please.  :-)


> [...]
> > Can you explain what potential concurrency problems are prevented by
> > explicitly holding kprobe_lock here (and at the unregister call)?
>
> kprobe_lock is used by kprobes to insert/remove probe to/from the
> list. This list might be in inconsistent state if kprobe_lock is not
> taken, hence we grab the lock before we walk the list.

OK, but then isn't there a race condition between concurrent
aggr-kprobes and raw kprobes callers?  That is, the struct being
protected by kprobe_lock could be invalidated by a raw kprobe user,
just after this code releases it, but while the aggregate lock is
still held.


- 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/20050408/1f1532be/attachment.sig>