[all-commits] [llvm/llvm-project] cf1319: [compiler-rt] Mark more calls as blocking (#77789)

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cf1319f9c6561afea381bbfc1a18f5c1fb7b46b0
      https://github.com/llvm/llvm-project/commit/cf1319f9c6561afea381bbfc1a18f5c1fb7b46b0
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
    M compiler-rt/test/tsan/pthread_atfork_deadlock3.c
    A compiler-rt/test/tsan/signal_in_read.c

  Log Message:
  -----------
  [compiler-rt] Mark more calls as blocking (#77789)

If we're in a blocking call, we need to run the signal immediately, as
the call may not return for a very long time (if ever). Not running the
handler can cause deadlocks if the rest of the program waits (in one way
or another) for the signal handler to execute.

I've gone through the list of functions in
sanitizer_common_interceptors and marked as blocking those that I know
can block, but I don't claim the list to be exhaustive. In particular, I
did not mark libc FILE* functions as blocking, because these can end up
calling user functions. To do that correctly, /I think/ it would be
necessary to clear the "is in blocking call" flag inside the fopencookie
wrappers.

The test for the bug (deadlock) uses the read call (which is the one
that I ran into originally), but the same kind of test could be written
for any other blocking syscall.



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