From: Olivier Dion <odion@efficios.com>
Date: Wed, 9 Aug 2023 21:35:40 +0000 (-0400)
Subject: ustfork: Fix possible race conditions
X-Git-Url: http://git.liburcu.org/?a=commitdiff_plain;h=cf54f06a38ed1f3a2ac49236ffb1f1e7b3024d87;hp=cf54f06a38ed1f3a2ac49236ffb1f1e7b3024d87;p=lttng-ust.git

ustfork: Fix possible race conditions

Assuming that `dlsym(RTLD_NEXT, "symbol")' is invariant for "symbol",
then we could think that memory operations on the `plibc_func' pointers can
be safely done without atomics.

However, consider what would happen if a load to a`plibc_func' pointer
is torn apart by the compiler. Then a thread could see:

  1) NULL

  2) The stored value as returned by a dlsym() call

  3) A mix of 1) and 2)

The same goes for other optimizations that a compiler is authorized to
do (e.g. store tearing, load fusing).

One could question whether such race condition is even possible for the
clone(2) wrapper. Indeed, a thread must be cloned to get into
existence. Therefore, the main thread would always store the value of
`plibc_func' at least once before creating the first sibling thread,
preventing any possible race condition for this wrapper. However, this
assume that the main thread will not call the clone system call directly
before calling the libc wrapper! Thus, to be on the safe side, we do the
same for the clone wrapper.

Fix the race conditions by using the uatomic_read/uatomic_set functions,
on access to `plibc_func' pointers.

Change-Id: Ic4be25983b8836d2b333f367af9c18d2f6b75879
Signed-off-by: Olivier Dion <odion@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---