Fix: rcutorture: work-around signal issue on mac os x
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thu, 8 Sep 2016 02:11:53 +0000 (22:11 -0400)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thu, 8 Sep 2016 02:13:59 +0000 (22:13 -0400)
Our MacOS X test machine with the following config:

15.6.0 Darwin Kernel Version 15.6.0
root:xnu-3248.60.10~1/RELEASE_X86_64

appears to have issues with liburcu-signal signal being delivered on top
of pthread_cond_wait. It seems to make the thread continue, and
therefore corrupt the rcu_head. Work around this issue by unregistering
the RCU read-side thread immediately after call_rcu (call_rcu needs us
to be registered RCU readers).

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
tests/regression/rcutorture.h

index 053653f..db3dfad 100644 (file)
@@ -368,9 +368,6 @@ void *rcu_update_stress_test(void *arg)
        struct rcu_stress *p;
        struct rcu_head rh;
 
-       rcu_register_thread();
-       rcu_thread_offline();
-
        while (goflag == GOFLAG_INIT)
                (void) poll(NULL, 0, 1);
        while (goflag == GOFLAG_RUN) {
@@ -399,7 +396,23 @@ void *rcu_update_stress_test(void *arg)
                                        strerror(errno));
                                abort();
                        }
+                       rcu_register_thread();
                        call_rcu(&rh, rcu_update_stress_test_rcu);
+                       rcu_unregister_thread();
+                       /*
+                        * Our MacOS X test machine with the following
+                        * config:
+                        * 15.6.0 Darwin Kernel Version 15.6.0
+                        * root:xnu-3248.60.10~1/RELEASE_X86_64
+                        * appears to have issues with liburcu-signal
+                        * signal being delivered on top of
+                        * pthread_cond_wait. It seems to make the
+                        * thread continue, and therefore corrupt the
+                        * rcu_head. Work around this issue by
+                        * unregistering the RCU read-side thread
+                        * immediately after call_rcu (call_rcu needs
+                        * us to be registered RCU readers).
+                        */
                        ret = pthread_cond_wait(&call_rcu_test_cond,
                                        &call_rcu_test_mutex);
                        if (ret) {
@@ -419,8 +432,6 @@ void *rcu_update_stress_test(void *arg)
                n_updates++;
        }
 
-       rcu_thread_online();
-       rcu_unregister_thread();
        return NULL;
 }
 
This page took 0.052836 seconds and 4 git commands to generate.