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] Design + prototype: Multiple kprobes at an address - take 2


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

Attachment: pgp00000.pgp
Description: PGP signature


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