[all-commits] [llvm/llvm-project] b999e6: [OpenMP] Fix node destruction race in __kmpc_omp_t...

[Ulrich Weigand via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b999e631c03640f7d1d93b5319da496ed4e0df55
      https://github.com/llvm/llvm-project/commit/b999e631c03640f7d1d93b5319da496ed4e0df55
  Author: Ulrich Weigand <ulrich.weigand at de.ibm.com>
  Date:   2024-03-28 (Thu, 28 Mar 2024)

  Changed paths:
    M openmp/runtime/src/kmp_taskdeps.cpp

  Log Message:
  -----------
  [OpenMP] Fix node destruction race in __kmpc_omp_taskwait_deps_51 (#86130)

The __kmpc_omp_taskwait_deps_51 allocates a kmp_depnode_t node on its
stack, and there is currently a race condition where another thread
might still be accessing that node after the function has returned and
its stack frame was released.

While the function does wait until the node's npredecessors count has
reached zero before exiting, there is still a window where the function
that last decremented the npredecessors count assumes the node is still
accessible.

For heap-allocated kmp_depnode_t nodes, this normally works via a
separate ndeps count that only reaches zero at the point where no
accesses to the node are expected at all; in fact, at this point the
heap allocation will be freed.

For this case of a stack-allocated kmp_depnode_t node, it therefore
makes sense to similarly respect the ndeps count; we need to wait until
this reaches 1 (not 0, because it is not heap-allocated so there's
always one extra count to prevent it from being freed), before we can
safely deallocate our stack frame.

As this is expected to be a short race window of only a few
instructions, it should be fine to just use a busy wait loop checking
the ndeps count.

Fixes: https://github.com/llvm/llvm-project/issues/85963



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications