Messages in this thread | | | Subject | Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17 | From | (Frank Ch. Eigler) | Date | 26 Sep 2006 15:49:34 -0400 |
| |
Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> [...] > > Yep, that looks reasonable. Though you could just directly test a > > per-marker enable flag, rather than using "condition"... > [...] > I am not sure I understand your suggestion correctly.. do you mean having > a per-marker flag that would be loaded and tested at every marker site ?
I gather that one reason for working so hard with the inline assembly is a race condition problem with the plain STAP_MARK style of marker disconnection:
if (pointer) (*pointer)(args ...);
Granted, but this problem could almost certainly be dealt with simpler than that. How about a compxchg or other atomic-fetch of the static pointer with a local variable? That should solve the worry of an (*NULL) call.
If we then become concerned with a valid pointer become obsolete (the probe handler function wanting to unload), we might be able to use some RCU-type deferral mechanism and/or preempt controls to ensure that this does not happen.
- FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |