port r17430 from 1.2: update component supposed race

tools/tsan/starpu.suppr

@@ -65,3 +65,9 @@ race:_starpu_data_unregister
 # ignore other libraries' races
 called_from_lib:^libmpi.so$
 called_from_lib:^libhwloc*.so$
+
+# see valgrind/starpu.suppr
+deadlock:starpu_pthread_mutex_lock_sched
+deadlock:_starpu_sched_component_lock_worker
+deadlock:_starpu_sched_component_worker_lock_scheduling
+deadlock:simple_worker_pull_task

tools/valgrind/starpu.suppr

@@ -161,8 +161,7 @@
 {
    TODO1: This is temporary. It perhaps does not pose problem because only the worker takes this mutex. Fixing this will require changing the scheduler interface, so that the schedulers themselves take the scheduling lock, not the caller. Filter it out for now, so we can see other races more easily.
    Helgrind:LockOrder
-   fun:pthread_mutex_lock
-   fun:starpu_pthread_mutex_lock
+   fun:mutex_lock_WRK
    fun:simple_worker_pull_task
    ...
 }
@@ -170,8 +169,8 @@
 {
    TODO1: This is temporary. It perhaps does not pose problem because only the worker takes this mutex. Fixing this will require changing the scheduler interface, so that the schedulers themselves take the scheduling lock, not the caller. Filter it out for now, so we can see other races more easily.
    Helgrind:LockOrder
-   fun:pthread_mutex_lock
-   fun:starpu_pthread_mutex_lock
+   fun:mutex_lock_WRK
+   fun:starpu_pthread_mutex_lock_sched
    fun:_starpu_sched_component_worker_lock_scheduling
    fun:simple_worker_pull_task
    ...
@@ -180,8 +179,7 @@
 {
    TODO2: This is temporary. It perhaps does not pose problem because only the worker takes this mutex. Fixing this will require changing the scheduler interface, so that the schedulers themselves take the scheduling lock, not the caller. Filter it out for now, so we can see other races more easily.
    Helgrind:LockOrder
-   fun:pthread_mutex_lock
-   fun:starpu_pthread_mutex_lock
+   fun:mutex_lock_WRK
    fun:_starpu_sched_component_lock_worker
    fun:simple_worker_pull_task
    ...
@@ -190,8 +188,7 @@
 {
    TODO2: This is temporary. It perhaps does not pose problem because only the worker takes this mutex. Fixing this will require changing the scheduler interface, so that the schedulers themselves take the scheduling lock, not the caller. Filter it out for now, so we can see other races more easily.
    Helgrind:LockOrder
-   fun:pthread_mutex_lock
-   fun:starpu_pthread_mutex_lock
+   fun:mutex_lock_WRK
    fun:_starpu_sched_component_lock_worker
    fun:_starpu_sched_component_worker_lock_scheduling
    fun:simple_worker_pull_task