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] |
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] |