rcutorture: Mark data-race potential for rcu_barrier() test statistics
authorPaul E. McKenney <paulmck@kernel.org>
Tue, 18 Feb 2020 21:41:02 +0000 (13:41 -0800)
committerPaul E. McKenney <paulmck@kernel.org>
Mon, 27 Apr 2020 18:05:13 +0000 (11:05 -0700)
The n_barrier_successes, n_barrier_attempts, and
n_rcu_torture_barrier_error variables are updated (without access
markings) by the main rcu_barrier() test kthread, and accessed (also
without access markings) by the rcu_torture_stats() kthread.  This of
course can result in KCSAN complaints.

Because the accesses are in diagnostic prints, this commit uses
data_race() to excuse the diagnostic prints from the data race.  If this
were to ever cause bogus statistics prints (for example, due to store
tearing), any misleading information would be disambiguated by the
presence or absence of an rcutorture splat.

This data race was reported by KCSAN.  Not appropriate for backporting
due to failure being unlikely and due to the mild consequences of the
failure, namely a confusing rcutorture console message.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
kernel/rcu/rcutorture.c

index 7e2ea0c..d0345d1 100644 (file)
@@ -1456,9 +1456,9 @@ rcu_torture_stats_print(void)
                atomic_long_read(&n_rcu_torture_timers));
        torture_onoff_stats();
        pr_cont("barrier: %ld/%ld:%ld\n",
-               n_barrier_successes,
-               n_barrier_attempts,
-               n_rcu_torture_barrier_error);
+               data_race(n_barrier_successes),
+               data_race(n_barrier_attempts),
+               data_race(n_rcu_torture_barrier_error));
 
        pr_alert("%s%s ", torture_type, TORTURE_FLAG);
        if (atomic_read(&n_rcu_torture_mberror) ||