user/sven/linux.git/kernel/marker.c, branch v2.6.26.6

markers: fix markers read barrier for multiple probes

2008-08-01T19:43:11Z

commit 5def9a3a22e09c99717f41ab7f07ec9e1a1f3ec8 upstream Paul pointed out two incorrect read barriers in the marker handler code in the path where multiple probes are connected. Those are ordering reads of "ptype" (single or multi probe marker), "multi" array pointer, and "multi" array data access. It should be ordered like this : read ptype smp_rmb() read multi array pointer smp_read_barrier_depends() access data referenced by multi array pointer The code with a single probe connected (optimized case, does not have to allocate an array) has correct memory ordering. It applies to kernel 2.6.26.x, 2.6.25.x and linux-next. Signed-off-by: Mathieu Desnoyers Cc: Paul E. McKenney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

make marker_debug static

2008-04-30T15:29:49Z

With the needlessly global marker_debug being static gcc can optimize the unused code away. Signed-off-by: Adrian Bunk Acked-by: Mathieu Desnoyers Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

kernel: explicitly include required header files under kernel/

2008-04-29T15:06:04Z

Following an experimental deletion of the unnecessary directive #include from the header file , these files under kernel/ were exposed as needing to include one of or , so explicit includes were added where necessary. Signed-off-by: Robert P. J. Day Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

markers: use synchronize_sched()

2008-04-02T22:28:19Z

Markers do not mix well with CONFIG_PREEMPT_RCU because it uses preempt_disable/enable() and not rcu_read_lock/unlock for minimal intrusiveness. We would need call_sched and sched_barrier primitives. Currently, the modification (connection and disconnection) of probes from markers requires changes to the data structure done in RCU-style : a new data structure is created, the pointer is changed atomically, a quiescent state is reached and then the old data structure is freed. The quiescent state is reached once all the currently running preempt_disable regions are done running. We use the call_rcu mechanism to execute kfree() after such quiescent state has been reached. However, the new CONFIG_PREEMPT_RCU version of call_rcu and rcu_barrier does not guarantee that all preempt_disable code regions have finished, hence the race. The "proper" way to do this is to use rcu_read_lock/unlock, but we don't want to use it to minimize intrusiveness on the traced system. (we do not want the marker code to call into much of the OS code, because it would quickly restrict what can and cannot be instrumented, such as the scheduler). The temporary fix, until we get call_rcu_sched and rcu_barrier_sched in mainline, is to use synchronize_sched before each call_rcu calls, so we wait for the quiescent state in the system call code path. It will slow down batch marker enable/disable, but will make sure the race is gone. Signed-off-by: Mathieu Desnoyers Acked-by: Paul E. McKenney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

markers: remove ACCESS_ONCE

2008-03-25T02:22:19Z

As Paul pointed out, the ACCESS_ONCE are not needed because we already have the explicit surrounding memory barriers. Signed-off-by: Mathieu Desnoyers Cc: Christoph Hellwig Cc: Mike Mason Cc: Dipankar Sarma Cc: David Smith Cc: "Paul E. McKenney" Cc: Steven Rostedt Cc: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

markers: update preempt_disable. call_rcu, rcu_barrier comments

2008-03-25T02:22:19Z

Add comments requested by Andrew. Updated comments about synchronize_sched(). Since we use call_rcu and rcu_barrier now, these comments were out of sync with the code. Signed-off-by: Mathieu Desnoyers Cc: Christoph Hellwig Cc: Mike Mason Cc: Dipankar Sarma Cc: David Smith Cc: "Paul E. McKenney" Cc: Steven Rostedt Cc: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

markers: don't risk NULL deref in marker

2008-03-05T00:35:14Z

get_marker() may return NULL, so test for it. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Jesper Juhl Acked-by: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

markers: fix sparse warnings in markers.c

2008-02-24T01:12:14Z

char can be unsigned kernel/marker.c:64:20: error: dubious one-bit signed bitfield kernel/marker.c:65:14: error: dubious one-bit signed bitfield Signed-off-by: Harvey Harrison Acked-by: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux Kernel Markers: support multiple probes

2008-02-14T00:21:20Z

RCU style multiple probes support for the Linux Kernel Markers. Common case (one probe) is still fast and does not require dynamic allocation or a supplementary pointer dereference on the fast path. - Move preempt disable from the marker site to the callback. Since we now have an internal callback, move the preempt disable/enable to the callback instead of the marker site. Since the callback change is done asynchronously (passing from a handler that supports arguments to a handler that does not setup the arguments is no arguments are passed), we can safely update it even if it is outside the preempt disable section. - Move probe arm to probe connection. Now, a connected probe is automatically armed. Remove MARK_MAX_FORMAT_LEN, unused. This patch modifies the Linux Kernel Markers API : it removes the probe "arm/disarm" and changes the probe function prototype : it now expects a va_list * instead of a "...". If we want to have more than one probe connected to a marker at a given time (LTTng, or blktrace, ssytemtap) then we need this patch. Without it, connecting a second probe handler to a marker will fail. It allow us, for instance, to do interesting combinations : Do standard tracing with LTTng and, eventually, to compute statistics with SystemTAP, or to have a special trigger on an event that would call a systemtap script which would stop flight recorder tracing. Signed-off-by: Mathieu Desnoyers Cc: Christoph Hellwig Cc: Mike Mason Cc: Dipankar Sarma Cc: David Smith Cc: "Paul E. McKenney" Cc: "Frank Ch. Eigler" Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux Kernel Markers: fix marker mutex not taken upon module load

2007-11-15T02:45:40Z

Upon module load, we must take the markers mutex. It implies that the marker mutex must be nested inside the module mutex. It implies changing the nesting order : now the marker mutex nests inside the module mutex. Make the necessary changes to reverse the order in which the mutexes are taken. Includes some cleanup from Dave Hansen . Signed-off-by: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds