Commit 30812f83 authored by Mathieu Desnoyers's avatar Mathieu Desnoyers Committed by Greg Kroah-Hartman

markers: fix markers read barrier for multiple probes

commit 5def9a3a 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: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent a3676137
...@@ -126,6 +126,11 @@ void marker_probe_cb(const struct marker *mdata, void *call_private, ...@@ -126,6 +126,11 @@ void marker_probe_cb(const struct marker *mdata, void *call_private,
} else { } else {
struct marker_probe_closure *multi; struct marker_probe_closure *multi;
int i; int i;
/*
* Read mdata->ptype before mdata->multi.
*/
smp_rmb();
multi = mdata->multi;
/* /*
* multi points to an array, therefore accessing the array * multi points to an array, therefore accessing the array
* depends on reading multi. However, even in this case, * depends on reading multi. However, even in this case,
...@@ -134,7 +139,6 @@ void marker_probe_cb(const struct marker *mdata, void *call_private, ...@@ -134,7 +139,6 @@ void marker_probe_cb(const struct marker *mdata, void *call_private,
* in the fast path, so put the explicit barrier here. * in the fast path, so put the explicit barrier here.
*/ */
smp_read_barrier_depends(); smp_read_barrier_depends();
multi = mdata->multi;
for (i = 0; multi[i].func; i++) { for (i = 0; multi[i].func; i++) {
va_start(args, fmt); va_start(args, fmt);
multi[i].func(multi[i].probe_private, call_private, fmt, multi[i].func(multi[i].probe_private, call_private, fmt,
...@@ -176,6 +180,11 @@ void marker_probe_cb_noarg(const struct marker *mdata, ...@@ -176,6 +180,11 @@ void marker_probe_cb_noarg(const struct marker *mdata,
} else { } else {
struct marker_probe_closure *multi; struct marker_probe_closure *multi;
int i; int i;
/*
* Read mdata->ptype before mdata->multi.
*/
smp_rmb();
multi = mdata->multi;
/* /*
* multi points to an array, therefore accessing the array * multi points to an array, therefore accessing the array
* depends on reading multi. However, even in this case, * depends on reading multi. However, even in this case,
...@@ -184,7 +193,6 @@ void marker_probe_cb_noarg(const struct marker *mdata, ...@@ -184,7 +193,6 @@ void marker_probe_cb_noarg(const struct marker *mdata,
* in the fast path, so put the explicit barrier here. * in the fast path, so put the explicit barrier here.
*/ */
smp_read_barrier_depends(); smp_read_barrier_depends();
multi = mdata->multi;
for (i = 0; multi[i].func; i++) for (i = 0; multi[i].func; i++)
multi[i].func(multi[i].probe_private, call_private, fmt, multi[i].func(multi[i].probe_private, call_private, fmt,
&args); &args);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment