port r14825 from 1.2: Add more valgrind suppressions. Use a suppression instead of temporarily disabling 'used_size' access, as that seems not threadsafe

src/datawizard/memory_manager.c

@@ -130,9 +130,7 @@ starpu_ssize_t starpu_memory_get_available(unsigned node)
 	if (global_size[node] == 0)
 		return -1;
 
-	STARPU_HG_DISABLE_CHECKING(used_size[node]);
 	ret = global_size[node] - used_size[node];
-	STARPU_HG_ENABLE_CHECKING(used_size[node]);
 	return ret;
 }
 

tools/valgrind/starpu.suppr

@@ -72,6 +72,49 @@
 }
 
 {
+   Ignore used_size statistics access
+   Helgrind:Race
+   fun:starpu_memory_get_available
+   ...
+}
+
+{
+   mc / handle locking order. We always take handle before mc, except when we tidy memory, where we use trylock, but helgrind doesn't handle that :/
+   Helgrind:LockOrder
+   ...
+   fun:_starpu_spin_trylock
+   fun:lock_all_subtree
+   ...
+}
+
+{
+   mc / handle locking order2
+   Helgrind:LockOrder
+   ...
+   fun:_starpu_spin_lock
+   fun:_starpu_memchunk_recently_used
+   ...
+}
+
+{
+   mc / handle locking order3
+   Helgrind:LockOrder
+   ...
+   fun:_starpu_spin_lock
+   fun:_starpu_request_mem_chunk_removal
+   ...
+}
+
+{
+   mc / handle locking order4
+   Helgrind:LockOrder
+   ...
+   fun:_starpu_spin_lock
+   fun:_starpu_allocate_interface
+   ...
+}
+
+{
    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