* Nick Piggin (nickpiggin@xxxxxxxxxxxx) wrote:
Mathieu Desnoyers wrote:
+#define MARK(name, format, args...) \
+ do { \
+ static marker_probe_func *__mark_call_##name = \
+ __mark_empty_function; \
+ volatile static char __marker_enable_##name = 0; \
+ static const struct __mark_marker_c __mark_c_##name \
+ __attribute__((section(".markers.c"))) = \
+ { #name, &__mark_call_##name, format } ; \
+ static const struct __mark_marker __mark_##name \
+ __attribute__((section(".markers"))) = \
+ { &__mark_c_##name, &__marker_enable_##name } ; \
+ asm volatile ( "" : : "i" (&__mark_##name)); \
+ __mark_check_format(format, ## args); \
+ if (unlikely(__marker_enable_##name)) { \
+ preempt_disable(); \
+ (*__mark_call_##name)(format, ## args); \
+ preempt_enable_no_resched(); \
Why not just preempt_enable() here?
Because the preempt_enable() macro contains preempt_check_resched(), which
may call preempt_schedule() which leads us to a call to schedule(). Therefore,
all those very interesting scheduler functions would cause an infinite
recursive scheduler call if we marked schedule() and used preempt_enable() in
the marker.
The primary goal for the markers (and the probes that attaches to them) is to
have the fewest side-effects possible : any kernel method called from an
instrumentation site adds this precise kernel method to the "cannot be
instrumented" list, which I want to keep as small possible.